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

[berarma]

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

That's not very reliable. It's a guessing game but also, how do you know what's unused code or data?

The answer to "how much is code?" is very variable. It's not only the kind of game, it's also how it's programmed. While some games might use memory conservatively, some might abuse it to gain some performance. There might be games using 1KB or 20KB of code. And if there's more memory available, like in the 128KB games, they could use even more. Although I think the code size of the games was often more limited by the time given to developers to finish the game.

[Lee Bee]

I totally appreciate that the size of code varies a lot, and this fact is useful to know.

But, statistically, there has to be some kind of "mean" average at the top of a bell curve. Whether the curve looks something like this:



Or is flatter like this:

[AndyC]

Not really, because it's a case of apples and oranges. Jetpac is a fantastically simple game and so has a tiny code base, more complex games like Batman or RoboCop will have a larger one because they have scrolling, masked sprites, complex enemy arrangements etc. Yet others, like the Freescape games move a lot of "code" into scripts run by an underlying engine - so that's data, but really it's a form of code even if not Z80 code.

And if you want to squeeze every last drop of performance out of the Z80, you can write custom routines for every single animation frame (this is more common on the CPC) and then you have "graphics" but really they're code.

[SteveSmith]

But, statistically, there has to be some kind of "mean" average at the top of a bell curve.

Does there? I'm not a statistician, but since the size of game code can be anything within a reasonable range, the "curve" could look like a mountain range.

[catmeows]

Not really, because it's a case of apples and oranges. Jetpac is a fantastically simple game and so has a tiny code base, more complex games like Batman or RoboCop will have a larger one because they have scrolling, masked sprites, complex enemy arrangements etc. Yet others, like the Freescape games move a lot of "code" into scripts run by an underlying engine - so that's data, but really it's a form of code even if not Z80 code.

And if you want to squeeze every last drop of performance out of the Z80, you can write custom routines for every single animation frame (this is more common on the CPC) and then you have "graphics" but really they're code.

It really boils down to simple count of special behaviour of NPCs/objects. Thats probably why Cybernoid has quite lot of code, there is lot of different enemies.

Looking on my WIP, simplest object is handled by script long 62 bytes while other 3 objects I have implemented already are handled by routines of 154, 161 and 186 bytes. There is also shared code the manages simple object database (find empty slot in db, call each object in db, player collision) and it takes just 304 bytes.

The video code (coloured sprites of two sizes 16x16 and 8x8 with clipping and y-axis sort, clear screen, paralax stars) takes 2K.
Sound routines (put effect in queue, resolve priorities, play bit of fx every interrupt) takes 367B.
Sprites take 192 bytes per frame (3x16 pre shifted to 4 positions) and they will consume by far most of memory.

[ParadigmShifter]

Well collect a load of data (you probably want to normalise it to take into account different program and data sizes i.e. make it in the range 0-1 where 0 = all data no code, 1 = all code no data) and run it through something like this which will estimate the probability density function for you

https://www.waterlog.info/cumfreq.htm

That's the easy part.

Collecting the data is the hard part.

* I'm not really a statistician either but I did do 2 years of statistics at university for my maths degree. Obviously we had to do all the tests by hand then.

It's probably going to look like a normal distribution (or maybe an F-distribution which has a wider tail) or a log-normal distribution I expect. If it is skew you may get better results by using 1 = all code no data, 0 = all data no code instead (i.e. turn original statistic s into new statistic s' = 1 - s).

https://en.wikipedia.org/wiki/Probabili ... on_fitting



Log normal is good for estimating things involving times usually and normal is good for most symmetric distributions.

[Lee Bee]

I did A-Level statistics.

the "curve" could look like a mountain range.

All small sets of data look like mountain ranges. However, we are talking here about a theoretically unlimited sample size, with a real data set of thousands of games. The bigger the sample size, the closer the chart will approach a bell curve (ie "normal distribution"). You would not expect to see multiple peaks appearing in the data without specific reasons for them to be there.

The shape of the graph is, of course, a completely separate issue to the fact that the division between "code" and "graphics" isn't always clearly defined.

[ParadigmShifter]

I can think of lots of reasons why games would have wildly different code vs. data distributions, and therefore averaging them may give a distribution with multiple peaks.

https://en.wikipedia.org/wiki/Multimodal_distribution

Some reasons off the top of my head:

* hardly any graphics (puzzle games say)
* procedural generation of content (Elite, Halls of the Things)

would be on the low end of data vs. code

* Massive game worlds
* games with loads of graphics animation frames

would be on the high end of data vs. code

You're probably best considering categories of games for that reason unless the categories are roughly evenly distributed which would smooth out the resulting probability distribution function.

EDIT: Which is why stuff like estimating heights of people they give a separate mean and standard deviation for males vs. females because while they are both approximately normally distributed, just averaging would not be a great fit for either. Similarly heights of poodles would not want to be mixed in with heights of great danes.

[Lee Bee]

Paradigm, you're arguing that different game genres will create distinct peaks of their own, just as the height of men and women create two peaks on a single chart.

In order for such distinct peaks to emerge, you'd need to have a small number of highly distinct game genres - a clustering together of several differnt kinds of game which all follow the same 'rule book'.

However, Spectrum games have countless genres which aren't clearly defined. The amount of graphics in puzzle games varies wildly. There is no suggestion that there would be a 'peak' at a small amount of graphics, when in fact you would expect there to be other games with slightly more graphics, and so on.

Given the large number of poorly-defined genres, I would very much expect all the data to approach a normal bell distribution as the sample size grows.

And even if the data set did contain multiple smaller peaks, that doesn't mean you can't find the overall average and the overall bell curve, to look at the general overall picture. That's all I wanted, the most basic overview.

[AndyC]

The thing is, 48K is simply not nearly enough memory to do much with. So games that need lots of logic, say strategy games like Gods, Chaos or Stonkers will have minimalist graphics simply as a result of running low on space. Whereas games like Dizzy will maximise graphics usage, at the expense of simplifying game logic as much as possible.

I'd expect the distribution is much less bell curve than you'd imagine.

[ketmar]

also, how should we count the code in Joffa engines, for example? Firefly JIT-compiles screen blitter for each frame… is jitted code a code? or is it a data, because it is created in a separate buffer? ;-)

[ParadigmShifter]

It's just a reserved data block. Might not even need to load it unless there is an existing template it just modifies (like changes PUSH and POP instructions).

I suppose once you start executing it it's technically code though.

[Bedazzle]

Heavy on the magick:

> words: 0x5E49-0x661D=0x07D5 ; 24137-26141=2005
> creatures: 0x661E-0x679E=0x0181 ; 26142-26526=385
> room names: 0x67A5-0x68A4=0x0100 ; 26533-26788=256
> astar tele: 0x68A5-0x68CC=0x0028 ; 26789-26828=40
> items desc: 0x68D4-0x6AB5=0x01E2 ; 26836-27317=482
> messages: 0x6ABD-0x6E47=0x038B ; 27325-28231=907
> trade pair: 0x6E4B-0x6E5A=0x0010 ; 28235-28250=16
> permit mon: 0x6E5B-0x6EB0=0x0056 ; 28251-28336=86
> trade item: 0x6EB1-0x6EBC=0x000C ; 28337-28348=12
> items data: 0x6EBD-0x7120=0x0264 ; 28349-28960=612
> rooms: 0x7137-0x753D=0x0407 ; 28983-30013=1031
> static cre: 0x7F7F-0x8020=0x00A2 ; 32639-32800=162
> specrooms: 0x84E4-0x84EA=0x0007 ; 34020-34026=7
> ai parts: 0x91D3-0x91D8=0x0006 ; 37331-37336=6
> phx parts: 0x9220-0x9221=0x0002 ; 37408-37409=2
> sav signs: 0xAE59-0xAF88=0x0130 ; 44633-44936=304
> sav items: 0xAF89-0xB278=0x02F0 ; 44937-45688=752
> spr data: 0xB9EC-0xBDEB=0x0400 ; 47596-48619=1024
> sprites: 0xBDEE-0xF905=0x3B18 ; 48622-63749=15128
> font: 0xF90E-0xFA8D=0x0180 ; 63758-64141=384
> music data: 0xFD2C-0xFFA4=0x0279 ; 64812-65444=633

below addresses are approximate:
code takes space from 0x7500 to 0xAF00
game save workspace is 0xAF00-0xB500
double buffer is 0xB400-0xBB00

[Lee Bee]

Thanks for the responses chaps, it's fascinating! I have another question…

I'm being told here by some that programmers don't want limits on their code size - the more space the better, ideally. Now that's something I personally agree with. I don't see anything "fun" about finding I've hit a limit and can't add any more code. (I feel the same about music, actually. The more space I have for music, the better I can make it.)

But on the other hand, I do know there are programmers in this community who enjoy the challenge of a limited size code, which is why 16k appeals to some.

What are your own feelings on this? Is a limit to code size sometimes fun - but usually not?

[ParadigmShifter]

It's just a challenge. (Obviously challenges can be fun too).

Obviously if you care about code size that much you need to program in assembly (or Ketmar will be along soon to mention Forth which also has a very compact code footprint), as soon as you get into higher level languages/compilation (maybe Forth and LISP get a look in here as well) you'll start getting code bloat. (EDIT: Unless you have an excellent optimising compiler which can optimise for size of code).

Which means it's not ideal for learners/beginners.

If designing a more modern retro platform you probably want to think of some amount of memory and then multiply it by a factor of 4-10x to give enough wiggle room.

[AndyC]

Taking away all the limits gives ultimate freedom but it can be crippling because you can become overwhelmed by the amount of work required. It's like being expected to write a multi-hour symphonic masterpiece for an entire orchestra, rather than a short looping chiptune.

But code size is a totally arbitrary measure and thus not really a useful limit as such. Multiplying two numbers might take a single byte or several hundred, depending on the architecture.

Far better is to limit the overall size of data you can work on and then force the code to be constrained by that, rather than necessarily "code size". It has the same overall effect of putting hard limits on what can be achieved, without requiring beginners to become frustrated that they don't necessarily know the most concise way to express something.

[ketmar]

But on the other hand, I do know there are programmers in this community who enjoy the challenge of a limited size code, which is why 16k appeals to some.

What are your own feelings on this? Is a limit to code size sometimes fun - but usually not?

it depends of a motivation. i mean, i, for example, won't even bother trying to write something serious for C64 or NES: i never had those machines, and i have no feeling towards them.

but ZX Spectrum 48K is the whole different story! i am basically doing the things i wanted to do as a child, but couldn't. so Speccy limitations doen't bother me a little.

so, for some device there are two kinds of people who embrace limitations: people who love that device, and people who feel competetive. (it is not mutually exclusive, of course. ;-) ah, of course, there are people who doing it strictly for money too, but that's not our case, i guess. ;-)

now, let's look on the problem from a slightly different side. i have ~40K for both code and data on Speccy. of course, this won't allow me to write something like Baldur's Gate 3… and it's good! because instead of suffering of constant feature creep, i may concentrate on the core gameplay, and add one or two bonus features later, if i'll still have room for them.

so it kinda helps to actually finish projects — because there is inevitable moment when you simply physically cannot add anything more. ;-)

but it is very hard to come up with some reasonable limits and hardware for such "limited system". historical systems got their limits… well, historically. and with a brand new system it is not that easy to decide what to include. AY? meh, why not SID, SID is much k00ler! MSX+ VDU? or some other VDU? or no VDU? 8-bit CPU? 16-bit? 32-bit? maybe two CPUs? and so on, so on…

or Ketmar will be along soon to mention Forth which also has a very compact code footprint

please, note that this time it wasn't me who started talking about Forth! ;-) (also, F8 is not compact anymore. ;-)

[Lee Bee]

Fascinating and informative responses, thanks!