PlayStation Development Network

Dear everyone,

Happy to join this forum. I have had the great fortune to come across a DTL-H2000, and have thanks to lameguy64's video's and the guide on this website, a working setup running (had to make the custom video connector and controller connector). This has been a real childhood dream come true. Since, I have programmed in C in the past, and I already work as a programmer for my profession, I did not have that big of a problem going through the various examples in the Technical Reference cd. Nevertheless, I am not clear yet on whether you can create cell data (tiles?) and bgd's (tilemaps) without the Sprite Editor, which will not start without the Graphic Artist board.
Does anyone have any experience to share. Did you create your own tilemap format that you then programmatically parsed to load the relevant tims into place?
I had seen some programs cracked to be used without the graphic's board, did anyone do the same for the sprite editor?

Thanks,

Joseph

You can simply generate a GsCELL array procedurally if you want to use the libgs functions for drawing tile maps. GsCELLs are basically just mapping information that point to a texture of a tile sheet in VRAM. As for the tilemap data, you'll have to make your own tilemap format that simply consists of a bunch of 16-bit unsigned shorts with 0xffff being the transparent tile entry and a simple header that defines the size of the map in tiles.

Personally, I prefer writing my own graphics routines in MIPS assembly as it offers better performance and greater control of how the tiles are processed, making it possible to implement more sophisticated effects in a very efficient manner.

I've been working on writing a tutorial series about PS1 graphics programming without using libgs (reason you'd want to consider not using libgs is program size) but It's been put it aside for awhile due to my busy work schedule and personal projects getting in the way. I'll try to get around releasing what I've written so far someday though and then writing more chapters whenever I find the time.

If it isn't the man himself!
Many thanks for your tutorial video's, they really help me find my way through setting up a dev kit.
Thanks for your answer. I really hope those videos get out, since, in the end, the whole fun of retro development is being forced to develop as efficiently as possible.

You're welcome on the tutorial videos I made and I'm glad to hear that they helped you in setting up your boards.

As for a video on writing custom graphics routines in assembly code, I don't really have any plans on making one at the moment as my main focus as of late has been Project Scarlet which is all 3D along with a super special project that is very likely the most impressive thing I've ever made which I'll show off once it's ready for prime time.

For a beginner PS1 programmer, I recommend sticking to using libgs for awhile and making simple games with it to familiarize yourself with programming for the PS1 and practice some low level stuff on it. Once you've become familiar enough you can take on low level graphics programming.

I do have some old tools and assembly code of a 2D tile engine left over from a cancelled game project. When I find the time I'll get around to tweaking them and releasing it on github.

ycelik wrote: ↑September 10th, 2018, 6:26 am retro development is being forced to develop as efficiently as possible.

Yes. Exactly. It actually takes proper skill unlike programming today on machines with speeds so fast that well structured code and optimisation isn't required.

Guys, while we are on the topic of efficient coding.
We can agree, when it is properly written, there are definitely occasions when Assembly code would trump higher level C code in speed. However, to what extent, I mean performance wise, does it matter whether you are coding in C or C++ for the Playstation? (While I have not tried it yet, if I remember correctly one should be able to code in C++ with the PSY-Q compiler, right?).

You can code in C or C++ (doesn't matter). What it comes down to is how well the compiler can optimise the high-level code to low-level code.

When you know the compiler isn't doing a good job with your routines, that's when you write it yourself in assembler to get the most performance out of the system hardware. The trick here is to use a little instructions as possible so for every cycle of the clock, the system doesn't executes unnecessary opcodes which the compiler may have added in from the C or C++ code.

As a really crude example, it's like using Google Maps on your phone. You might know a faster way to get to your destination, but Google keeps telling you to go another way even though it is slower. Google (or the compiler in this case) is systematically doing what it was told to do.

I love that example Shadow!

Shadow wrote: ↑September 20th, 2018, 8:15 pm The trick here is to use a little instructions as possible so for every cycle of the clock, the system doesn't executes unnecessary opcodes which the compiler may have added in from the C or C++ code.

On a processor like the PS1, reducing the number of instruction is not the biggest optimization, the most important is the optimization of the pipeline

Kannagi wrote: ↑September 21st, 2018, 5:06 pm

Shadow wrote: ↑September 20th, 2018, 8:15 pm The trick here is to use a little instructions as possible so for every cycle of the clock, the system doesn't executes unnecessary opcodes which the compiler may have added in from the C or C++ code.

On a processor like the PS1, reducing the number of instruction is not the biggest optimization, the most important is the optimization of the pipeline

Yes, there is that too, but as a beginner trying to understand pipeline optimisation is tricky

You're right, on PS2 and Dreamcast, I already break my head with that ah ah

The only other CPU side optimizations I can think of on the PS1 other than utilizing branch delay slots as much as possible is aligning your code to cache which from what I've observed is extremely difficult to do right as your procedures (assembler or C) tend to move around as you write more code to your program.

LameGuy64 wrote: ↑September 8th, 2018, 1:39 am As for the tilemap data, you'll have to make your own tilemap format that simply consists of a bunch of 16-bit unsigned shorts with 0xffff being the transparent tile entry and a simple header that defines the size of the map in tiles.

Speaking of tilemaps, can one use Tiled-based maps as a tilemap for PS1? I know such tool that can convert XML-based tilemaps to easy read binary format for older type consoles (TMX2BIN - By Onorisoft).

For tilemap (and cell pixel art).... i've been getting into https://tilestudio.sourceforge.net/
It's really old and it gets really slow on big maps (> 64x64) but it does everything and it's opensouce!
I think it's strengths are the script export (text or binary) and it's simplicity.




Regarding, the renderer, I'd recommend rolling your own, it's not that hard and it's portable and if you do it right you get collision for not much extra work!