How much of a 48k game is graphics? How much is code?

[Lee Bee]

Anyone know roughly what's the split of code to graphics for a "typical" 48k game? Is code normally smaller?

[Morkin]

It'll probably vary on the type of game.

Might need to ask "for a game like X"

[ParadigmShifter]

Each is as long as a piece of string.

Why not pick some games from this list

https://skoolkit.ca/links/

and look at the disassembly e.g. here's Luny's disassembly of Marsport which has code flagged in green, data flagged in pink

http://luny.co.uk/gargoyle/marsport/maps/all.html

Usually you can change from hex to decimal addresses but it seems not for that one. So if you want to work out the size of code vs. graphics/data you'll probably need to get your Windows calculator out in programmer mode or use a spreadsheet which will probably be able to convert from hex to decimal and work out sizes of things. Or maybe there's a skoolkit specific way to produce the info you want.

But it's not really a sensible question since you can increase code size to improve speed, compress graphics, etc. It all depends.

If you want to analyse a few of those games and tell us the results then feel free to do so, don't expect anyone else to do it though, since everyone knows the answer already: it depends

Code is usually shorter than data though but I like to unroll a lot of code to make it run faster myself so my code is probably larger than average. But if I run out of memory I can cut back on the amount of unrolling I do to save memory later on. EDIT: I'm also working on a puzzle game and there are hardly any graphics at the moment (5x32 byte tiles = 160bytes + a few more bits of graphics I use to change the tiles a bit when selected/being previewed (only about 96 bytes + a few more for that), a few attributes for each tile (10 or 20 bytes, can't remember) and the total code size is about 11K atm (but there is a lot of gaps in the code I can fill later on by moving stuff around, it is in development). That includes 768 bytes reserved for a buffer to cope with scrolling parts of the screen, 768 bytes for the attribute layer and then there's the data (e.g. the collision map is 11x16 bytes) which isn't huge at the moment. If I want a custom font that's up to 768 byte as well but I am not using one yet.

EDIT: For SJOE, there were 26 letter 16x16 tiles at 32 bytes each + 10 number 16x16 + a few icons used in the main menu (maybe 10 or so) so lets say 50x32 bytes for that = 1600 bytes? There was also a 768 byte font (which had some characters remapped to other useful 8x8 sprites e.g. the edges of the printout and arrows indicating which directions you made words in). So lets call that 2.5K or so?

Then there was an attribute buffer but only for the right hand side of the screen IIRC so something like 10x24 = 240 bytes I think.

Variables and high score tables used up a few hundred or so bytes maybe. Oh forgot the collision map, again that was 16x11 = 176 bytes. 48 bytes for the screen address lookup table too. So lets estimate all that at around 500 bytes maybe.

The dictionary of all the 4 letter words was the most data which was about 16K.

I don't know how large the music and SFX were, maybe 2K or so tops.

Everything else was code I think. Menu code and data was about 6K I think (font also lived in the menu code and data area IIRC).

I think the finished game was around 40K but there were quite a few blocks of unused memory (if you load it from the tape you can hear the blocks of 0s being loaded).

You can also listen out for stuff as a game is loading it's not hard to tell the difference between code (sounds pretty random) and graphics (sounds a bit more regular, similar to how a loading screen loading sounds).

So listening to SJOE loading it immediately starts with a bunch of code (random sounding stuff) then has some graphics data after that, then a block of zeroes (about 2K I think?) until it hits address 32768. Then a load of code again for a bit, then the words list (which sounds quite regular too) then graphics again, and then global variables and buffers (many of which start off with 0s as well). Then there's another short gap of zeroes, then the Music and SFX code and data, followed by the attribute buffer at the end, followed by the ISR vector table and code for the ISR I think. Then it has loaded.

[ketmar]

i wonder why OP is interested. prolly they have some bigger question in mind. @Lee Bee, if this is true, could you tell us that bigger question, please? ;-)

[Lethargeek]

usually the code takes 10-20k depending on the game type (for an AGD game it's about 15k for example)
as for the rest, besides the gfx and sound the level data may take any amount (there are games with huge maps)

[AndyC]

Yeah, 10-20K sounds about right to me, then there is obviously about 8K for the screen and system variables. So you're looking at around 20K for level data, music and graphics plus any buffers that might be needed - which might be a fair few KB themselves if you're scrolling and need off screen buffers for preparing the frame and a "clean" background buffer.

[Lethargeek]

as for the buffers, most scrolling games use a full back buffer for the scrolled area, flip-screen games may use several smaller buffers for "dirty" parts of the screen instead; also most 48k games do not use big tables, usually just 256b for mirroring; a notable exception is la churrera with its 3.5k table for horizontal sprite shifting

[ParadigmShifter]

You can also use 16 bytes for a mirror table if you want and mirror each nybble separately if you start running out of memory too. That's a bit slower but you can do it without shifting if you store the mirrored nybble data in the both the high and low nybbles so you don't need to shift, just mask.

I once had a full 256 byte mirror table in Manic Miner Turbo but I commented it out since I didn't need it in the end (there's separate animation frames for right and left facing guardians). I also run-length encoded the level data in that (e.g. at 12, 6 we have 7 horizontal tiles of this type) which saved a load of memory... and there was a lot of bits in the RLE compressed format I could have saved as well but didn't bother with (like packing X, Y positions into 9 bits [32x16 = 512 possibilities] and using the spare bits for something else).

Obviously large lookup tables or preshifting make things much faster though.

When it comes to preshifting or not if you know what sprites appear on a screen in a flip screen/level based game for example, you can preshift the sprites needed on entry to the screen into a buffer.

[Lee Bee]

Thanks, chaps, that's really helpful info! I forgot about level data.

I appreciate that every game is different, but there's still going to be a 'bell curve' average.

i wonder why OP is interested. prolly they have some bigger question in mind. @Lee Bee, if this is true, could you tell us that bigger question, please?

I have two reasons, actually:

1. First and foremost, I'd love to make a Speccy game someday and wanted some idea how much room the code will take up so I can plan the scope of the other data.

2. My other reason is more long-term: for years I've been designing a new games platform that will run small 8-bit-style games. I've been trying to get a handle on what is a comfortable amount of space for game code so I can set a reasonable limit.

[Cheez26]

@Lee Bee Well, to be honest, there are plenty of fantasy consoles that go for that 8-bit look. Especially Pico-8. So, forgive me, but why make another 8-bit platform? What can you bring to the table that fantasy consoles like Pico-8 and even Tic-80 already provides? Is it gonna be hardware like the Playdate? Not trying to be a downer. Just really curious, that's all.

[ParadigmShifter]

You don't want to set a limit on code size anyway, just have all the memory available for whatever purpose you need? Anything that does set a limit (e.g. PS1 had 2MB main memory, 1K (lol) very fast cache* memory, 1MB VRAM, 512K (not enough) sound RAM IIRC) also had mass storage devices so you could juggle what was in memory at any one time. Devkits had 8MB RAM (might have been 4MB, was a long time ago) as well which was nice.

But there's also no point reinventing the wheel lots of good 8-bit platforms or 8-bit platform alikes exist already.

* Wasn't really what we would call a cache these days it was just very fast memory on the CPU. Most people put their stack there and maybe some very important global variables. There was also a global pointer register which meant 64K was accessed faster than the rest of main memory (kind of like zero page addressing on 6502)

[AndyC]

2. My other reason is more long-term: for years I've been designing a new games platform that will run small 8-bit-style games. I've been trying to get a handle on what is a comfortable amount of space for game code so I can set a reasonable limit.

The number would be entirely different in that case though. Any "fake" CPU usable for simple modern code could easily do far more than a Z80 instruction will. And, to be honest, there is little point limiting the amount of code you can have, just limit the number of 8*8 tiles, sprites and the size of level data and it'll be suitably constrained.

[Lee Bee]

You don't want to set a limit on code size anyway

While your advice is greatly appreciated, you don't know the first thing about my project, what it is, the hardware involved, either of the machine or the games, or anything about the architecture, how games are distributed, stored and shared, which means speculation is irrelevant!

forgive me, but why make another 8-bit platform?

Thanks for your interest in my project. This is actually the first time I've spoken about it publicly. I'm still years off making any public announcements and can't go into detail. I will say that what I'm developing is something physical, not a fantasy console. It's not 8-bit and not retro, but the games are small and have some similarities to 8-bit games.

There's no single "USP" because it's a totally new kind of videogame experience and there's never been anything like it, different to any console that's ever existed before. It's not even a console. No one has even come close to ever doing anything like this. It features a completely new graphics system which I believe is also going to revolutionise the field of art, as well as several other fields which I can't disclose yet. It's not for profit, only to make the world a better place. Plus, corporations like Nintendo can't replicate my system because the entire concept is based around an artistic work which I own the copyright to. That's just about as much as I can say right now

[ketmar]

I have two reasons, actually:

1. First and foremost, I'd love to make a Speccy game someday and wanted some idea how much room the code will take up so I can plan the scope of the other data.

i'd say that the best way is to write an engine first. at least some essential parts of it, like rendering a frame. because you might not need a back buffer, for example (or have it very small, like in XTE), or you may need a huge back buffer for, i.e., scrolling. and after measuring the speed of your engine, you may use on-the-fly flipping, for example (yet another table), and table-based shifting (another big table), or you could find out that your game is fast enough to shift with the usual "add hl, hl", and you can use free space to store mirrored sprites.

it is highly depends of your game, and it is really hard to estimate before you actually do it.

with some expirience you may avoid writing the code, because you'll know (roughly) how much space your engine will take. but to make such estimates, you need to write many different engines first. ;-)

2. My other reason is more long-term: for years I've been designing a new games platform that will run small 8-bit-style games. I've been trying to get a handle on what is a comfortable amount of space for game code so I can set a reasonable limit.

it is, again, highly depends of hardware specs. support for hardware sprites, for example, may drastically change the memory requirements. ditto for hardware scrolling, and such.

again, you'd better write some games (of different kinds: flip-screen, scrolled, etc.) for Speccy, MSX, NES to get a "feeling" of it, and to learn what benefits each kind of hardware acceleration may give.

[Lee Bee]

Thanks, Ketmar.

[ParadigmShifter]

Ok well programmers don't like being limited in how much of the main memory they can use which is 1 thing the N64 got right I think (never programmed for that though).

If you use modern CPU you will have enough memory anyway to not need to worry about it.

But maybe you know better than all these programmers here though about hardware and distribution etc. The most important thing a new platform needs is software so you'd best get cracking on with that anyway. Make sure you provide a decent library so they can also get writing stuff quickly.

I'm probably a noob with only a few commercial releases on PS1, PS2, PS3, Wii, Xbox360 and PC. And all that time I wasted doing device drivers and working on hardware simulations of CPU components for new silicon chips for some client called "Star", which I think was a code name for some company named after a piece of fruit.

[Lee Bee]

Paradigm, thank you, I do appreciate your interest and advice. Please note that I wasn't questioning your credentials, merely pointing out that you don't know the first thing about my project, and therefore speculation (even from an expert) would be pointless.

It's not that I don't want to hear your views on programming for consoles, what you said about N64 is fascinating and I could listen to those views all day. (I'd love to chat with you and find out more.) It's just that right now - no one is in a position to give me specific advice on this project because no one knows any details!

I haven't said what the loading speed is, tape size, storage medium (if any). I've given no details about my financial model or how file size relates to physical weight, convenience, or user and manufacturer cost. Am I paying for online hosting? I've said nothing about the context in which games are programmed or played, or by whom. Is it aimed at experienced programmers such as yourself? Or is it a system for training cats to use a computer? Perhaps the games are type-in games printed on the back of cat food packets? This would create a finite limit to game size.



My point is it's not "another console", it's something very new, with games that are small and simple for deliberate reasons, which I haven't disclosed. Cats may or may not be involved, but probably not.

[ketmar]

i smell Nintendo's "Game & Watch" here. ;-)

sorry, i simply couldn't kept that joke to myself. no offences, please, i'm not trying to make fun of you or your ideas: trying to bring something new on the table is always great, even if it won't materialize. the attemt itself is already valuable.

[Cheez26]

i smell Nintendo's "Game & Watch" here.

To be honest, I've always wanted a color Playdate or whatever that handheld with the crank is called, so it's probably less related to G&W and more related to, well, Playdate.

[catmeows]

1. First and foremost, I'd love to make a Speccy game someday and wanted some idea how much room the code will take up so I can plan the scope of the other data.

15KB is usually enough for 2d game, often much less, whole Jetpac fits into 8KB.

[MustardTiger]

20% for code seems right to me.

You can load .SNA or .TAP files into an image viewer and get an idea of what's code and what's graphics and data. I used Irfanview to generate these images and added my own guesses about what was data and code. Irfanview lets you import any file as raw data so I set it to display as 1bit per pixel with 512x1024 resolution.

Cybernoid


Knight Lore


Manic Miner

[Morkin]

Just had a look. For Balachor's Revenge (fairly simple game, tile based map, lots of screens, flip screen sprite game), it was something like:

Map data storage (uncompressed) - ~9k
Graphics (uncompressed) - ~13k
Code - ~8k

There's also a fair amount of text (compression/tokenisation used to reduce size slightly).

[PeteProdge]

[Lee Bee]

MustardTiger, that is absolutely brilliant, thank you!

As for my project, I'm sorry to be cagey at this point. It's still way too early to make any announcements, but when the time is right I can't wait to share everything.

My idea might be a monorail. We'll see.

[ketmar]

that's why i have "sprview" tool in ZXEmuT — to avoid abusing other tools. (and to easily steal sprites too. ;-)