Tilemap best practices

Post a topic about yourself to let others know your skills, hobbies, etc.
Post Reply
ycelik
Curious PSXDEV User
Curious PSXDEV User
Posts: 20
Joined: Sep 02, 2018

Tilemap best practices

Post by ycelik » September 7th, 2018, 7:26 pm

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

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » September 8th, 2018, 1:39 am

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.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

ycelik
Curious PSXDEV User
Curious PSXDEV User
Posts: 20
Joined: Sep 02, 2018

Post by ycelik » September 10th, 2018, 6:26 am

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.

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » September 10th, 2018, 10:10 am

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.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » September 10th, 2018, 3:05 pm

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.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

ycelik
Curious PSXDEV User
Curious PSXDEV User
Posts: 20
Joined: Sep 02, 2018

Post by ycelik » September 13th, 2018, 10:50 pm

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?).

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » September 20th, 2018, 8:15 pm

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.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

likeabaus
Extreme PSXDEV User
Extreme PSXDEV User
Posts: 133
Joined: Jul 27, 2016

Post by likeabaus » September 20th, 2018, 11:35 pm

I love that example Shadow! :P

Kannagi
Interested PSXDEV User
Interested PSXDEV User
Posts: 6
Joined: Apr 30, 2018
I am a: Retro-Programmer
PlayStation Model: SCPH-7502
Location: France

Post by Kannagi » 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 ;)

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » September 23rd, 2018, 1:49 pm

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 ;)
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

Kannagi
Interested PSXDEV User
Interested PSXDEV User
Posts: 6
Joined: Apr 30, 2018
I am a: Retro-Programmer
PlayStation Model: SCPH-7502
Location: France

Post by Kannagi » September 23rd, 2018, 10:24 pm

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

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » September 25th, 2018, 12:30 pm

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.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
Elvarg
Interested PSXDEV User
Interested PSXDEV User
Posts: 6
Joined: Aug 24, 2020
Discord: Elvarg#5843

Post by Elvarg » September 28th, 2021, 2:49 am

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).

User avatar
gwald
Verified
Net Yaroze Enthusiast
Net Yaroze Enthusiast
Posts: 282
Joined: Sep 18, 2013
I am a: programmer/DBA
PlayStation Model: Net Yaroze
Contact:

Post by gwald » December 28th, 2022, 10:31 pm

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!

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests