|  Post Your Message | |
| |
| | Previous Messages | Posted By
Csabo
on 2022-04-15
16:03:49
|  Re: Memory layout in games
This is trickier, I guess I can only chime in with my example: Domino Deluxe does some automatic disk load/save for the highscores. For this, and only this, the code uses the KERNAL. (With proper error handling! If you don't have a disk in the drive, or it's full or write protected, the error is cleared up so that the drive won't blink indefinitely... Arrgh, that's one of my pet peeves, the vast majority of stuff doesn't do this properly.) For that part, the music's volume is lowered, and ROM is banked in.
For me, compatibility (nearly) trumps everything else, which is why I avoid fast-loaders and fast-savers. (For something like high scores, you wouldn't need tham anyway.) The KERNAL always works, end of story. On the other hand, I haven't really worked on anything that requires very extensive loading, so others can probably offer better insight. (Off topic: CD5 is the most compatible megademo on Plus/4, bar none... PAL/NTSC, can be started from any part, can be run as single parts, uses disk turbos only when properly detected, even loads from tape, etc.)
|
|
Posted By
Spektro
on 2022-04-15
01:22:27
 | Re: Memory layout in games
Do you use Kernal subroutines in your games or just keep the ROM banked out and use your own custom routines for reading files, printing on the screen, etc?
|
|
Posted By
gerliczer
on 2022-04-14
10:31:31
| Re: Memory layout in games
I second Csabo and Mad. Furthermore, when you create a little bit more CPU demanding code, you may find yourself in situations where optimal arrangement of large or many lookup tables will dictate your memory layout. Then you'll be happy to find one single contiguous area where you can put your chargen or video matrix in extreme cases. Although it is not game related but when I wrote Sweet DFLI C=16 I had to do a thorough layout test on where to put the graphics so it wouldn't overlap with the luma/chroma matrices. And everything else had to be stashed into the remaining "holes" in memory.
|
|
Posted By
Mad
on 2022-04-14
09:59:37
| Re: Memory layout in games
Almost the same here. The only thing which could be interessting to mention is, that on a Hannes256k you only have the memory from $1000 onwards (or maybe $4000 just don't remember the exact specs), at least the core interrupt routines should reside in that lower area.. So this would be the only limiting factor I would take into consideration for placing code or graphics.. Of course if you do have a cartridge maybe this would also limit the memory choices. So to say, it really doesn't matter that much where you place graphics.. If you do multiload games you would have to juggle with a lot of different areas anyways, because you don't want to turn of the screen there. Or if you are a very orderly programmer and really think about a standard memory layout for all files/screens/modes of the game then maybe it would make sense to think about that before, but I think that is too limiting (for me personally).
|
|
Posted By
Csabo
on 2022-04-14
08:14:37
| Re: Memory layout in games
This may not be a particularly helpful answer but: this varies wildly and depends on the game. In the age of cross-platform compilers, memory locations don't matter that much, labels and "align" directives (or equivalent) take care of this stuff without the coders having to think about it.
Last year I worked on Candy Dots, Defiance, Nu, Pogodi!, Stop The Express, Tetris 2K21 (among others) - they are all very different. I considered a 16K version for all of them, but where it wasn't feasible, I didn't want to essentially write a 2nd game. Defiance fit easily, Tetris was a bit of challenge due to having graphics screen, so music and other stuff had to be omitted.
|
|
Posted By
Spektro
on 2022-04-14
02:43:19
| Memory layout in games
I'm curious, which memory areas do you use for the text screen, graphics screen, and music/interrupt routine in your games? Where do you store the graphics data (characterset and graphic tiles)?
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
