How to improve the game competition...

[Gryzor]

Bringing the thread back from the dead.


Hopefully people have cooled down a bit now summer has ended, so if anyone has any thoughts let's hear them

[TFM]

From my side... I made a lot of good suggestions. Just pick em up if you like.


From the side of others... 

[dcdrac]

maybe have categories like roleplay, shoot em up, strategy, enhanced versions across the various devices and make it more than 16K?

[TFM]

Well, we had four entries at the first attempt. I don't know if it would make sense to introduce categories. But on the other hand in this case we only would have first places 


However, your idea to allow 32 KB games too is good. For voting the used amount of ROM should be considered too.

[redbox]

However, your idea to allow 32 KB games too is good. For voting the used amount of ROM should be considered too.

These two statements contradict each other: allow twice the size of the previous competition yet award kudos for the amount of space used...

No point in 32kb IMHO - may as well just code a normal 464 game.

[TFM]

A normal 464 game fits in a single 16 KB ROM w/o a problem.[nb]Using Exomizer[/nb]




Ok, so which ideas do you have?

[redbox]

Ok, so which ideas do you have?

Maybe don't promote it as purely a ROM competition next time (although the benefit is that they can easily be made into ROMs at this size) but keep the size limit to ensure good programming and fresh ideas...?

making access easier for non CPC users is a very good idea (alongside promotion etc) because it will then hopefully interest the whole retro gaming community and might well get more people involved with the CPC at the same time.

[AMSDOS]

so if anyone has any thoughts let's hear them

Make an Amateur & Professional game compo so people don't freak. 

[gerald]

A normal 464 game fits in a single 16 KB ROM w/o a problem

Well, I do not call that a ROM game. Using the ROM banking as a simple mass storage replacement is just trivial 
What about true ROM games, which execute they main code from ROM.

BTW, please define normal 

[TFM]

BTW, please define normal 

Ask him:

No point in 32kb IMHO - may as well just code a normal 464 game.

[TFM]

Well, I do not call that a ROM game. Using the ROM banking as a simple mass storage replacement is just trivial 
What about true ROM games, which execute they main code from ROM.

Where is the advantage to execute code in a ROM for a GAME? Like usually you tell some crap, just to offend somebody else. Your comments are not helpful at all, but they tell us a lot about your character. 

[redbox]

Ask him:

32kb for game code + 32kb for video RAM (double buffered) = 64kb = CPC464.

Like usually you tell some crap, just to offend somebody else. Your comments are not helpful at all, but they tell us a lot about your character.

I think you're describing yourself here TFM.

Gerald's comments and input has been a lot more helpful than yours.

[TFM]

Oh really, which one?    Grow up guys!

[ralferoo]

Where is the advantage to execute code in a ROM for a GAME? #

It should be obvious. You have all the RAM available, so you could double or triple buffer the video memory. You could use double buffered overscan and still have a usable amount of RAM left over. You don't have a startup delay for decompression running straight from ROM. You could run the main game from ROM and adaptively decompress small chunks, say a screen or level at a time. You could use the extra RAM for lookup tables which you wouldn't have the memory for if the game code was in RAM too.

This stuff is all common sense and there are so many examples if you stop to think about it. RAM is a precious resource and there's no point squandering it unnecessarily. If you've got a guaranteed connected ROM, why use it only for 5 seconds at boot and then never again?

An example: Does future os decompress itself into RAM when you launch it? Or does it instead do the sensible thing and treat RAM as the scarce resource that it is and run from ROM so applications have more RAM available? It's exactly the same point.

Of course it could be that future os decompresses into RAM. If so, no wonder you're such an advocate for having 576KB RAM... 

Like usually you tell some crap, just to offend somebody else. Your comments are not helpful at all, but they tell us a lot about your character. 

Plus ça change... 

[Sykobee (Briggsy)]

Thanks ralferoo and gerald - IMO a game in the ROM competition should run from the ROM and use RAM for calculated and changing data.

Sure, use exomiser to decompress level data into RAM (on a per-level basis), and graphics data (which compresses well, and can easily use up tonnes of ROM otherwise, ditto for the per-level basis).  But as has been pointed out, using ROM as an alternative to tape or disc is not making the best use of the medium.

Indeed I don't really mind if the competition is 16KB and 32KB - the latter will allow for more levels and graphics.

But having all that RAM available for massive levels, double buffering, large screens, runtime game data (enemy stats in an CRPG game with dozens of enemies needs loads of RAM) - that is invaluable, and it can lead to games that weren't previously attempted on the CPC, or not done as good as they could have been.

[TFM]

It should be obvious. You have all the RAM available, ...

Well, if there are 64 KB or RAM and 16 KB of ROM, then code execution in the ROM is a bad choice for the following reasons:


- Uncompressed program is limited to 16 KB (since you can't uncompress from ROM to ROM).
- Double buffering is nice, and often used, but triple buffering no serious coder would use. So 32 KB of RAM are still way too much to store a couple of variables in it instead of using the full 32 KB for (decompressed) code.
- The reason for using a ROM is a quick loading time of the game, but NOT that your code can run in ROM.

- And now the killer argument: Code executed in ROM can't be self modifying!


BTW: Every dump piece of code can be executed in ROM, there is not difference to be executed in RAM. However, sophisticated self modifying routines need RAM and not ROM.

Thanks ralferoo and gerald - IMO a game in the ROM competition should run from the ROM and use RAM for calculated and changing data.

If you ever would try to code a game you would change your opinion quick.

And btw: 100% of all games participating in the ROM compo 2013 did use the ROM as storage for compressed data. They all did run in RAM, and there are good reasons for that. But maybe one has to start coding first to understand the reasons (see before).

[ralferoo]

- And now the killer argument: Code executed in ROM can't be self modifying!
BTW: Every dump piece of code can be executed in ROM, there is not difference to be executed in RAM. However, sophisticated self modifying routines need RAM and not ROM.

That's hardly a killer argument. You can easily copy the small amount of code that needs to be self modifying to RAM and run the rest from ROM.

If you ever would try to code a game you would change your opinion quick.

That's funny, that's what I do for a living. 

And btw: 100% of all games participating in the ROM compo 2013 did use the ROM as storage for compressed data. They all did run in RAM, and there are good reasons for that. But maybe one has to start coding first to understand the reasons (see before).

Sure, that's because either they were too big to fit in 16KB ROM uncompressed, or because they just found it easier to develop in RAM on a normal emulator first. Maybe they didn't need any more RAM, so that's fine too.

There are plenty of reasons why one might want to use RAM. I listed a load earlier. Oh, here's another one too: it doesn't matter what state the RAM banks are in if you're using 128KB.

I could have come up with some disadvantages too, there are some obvious ones you've missed. But the thing is, you specifically asked what the advantages of running directly from ROM were and then got argumentative when I listed some. Or have you forgotten writing this just before you started insulting gerald?

Where is the advantage to execute code in a ROM for a GAME?

[Bryce]

The fact that the ROM is paged into the same address space as the screen means that a game running directly in ROM is always going to be slower than one that's resident in RAM. So it makes sense to always run the game from there.

Bryce.

[gerald]

- Uncompressed program is limited to 16 KB (since you can't uncompress from ROM to ROM).
- And now the killer argument: Code executed in ROM can't be self modifying!

Executing from ROM does not mean that you cannot have part of your code running in RAM.

- Double buffering is nice, and often used, but triple buffering no serious coder would use. So 32 KB of RAM are still way too much to store a couple of variables in it instead of using the full 32 KB for (decompressed) code.

May be  Chiken Killing games only requires a couple of variables. But game does not only mean hunting.
You may want to store in RAM :
   - procedurally generated data for level, gfx
   - Status variable (Civilisation/SimCity like ...)

And btw: 100% of all games participating in the ROM compo 2013 did use the ROM as storage for compressed data. They all did run in RAM, and there are good reasons for that. But maybe one has to start coding first to understand the reasons (see before).

Yep, and this is one of the reasons for suggesting ROM based execution. Where is the fun of a ROM competition if ROM is only used like a tape or drive.
Basically, a ROM competition entry should not work if not in ROM 

[TFM]

Well, everybody shall feel free to do own productions in the way that pleases the most. I like perfection and efficiency    And I base my work on a pragmatic POV.




If s/o want's to run things in ROM fine! If half of it get's copied into RAM, fine too!


Happy weekend to all coders and anybody else 

[TFM]

@gerald and raliferoo: I'm looking forward to your first production on Amstrad CPC. 

[andycadley]

The fact that the ROM is paged into the same address space as the screen means that a game running directly in ROM is always going to be slower than one that's resident in RAM. So it makes sense to always run the game from there.

Huh?

You can put the screen wherever you like and if you don't need to read from it, then it can happily sit under the ROM too. Contention on the CPC is universal, so it doesn't matter where code executes, it'll still run at the same speed (unlike machines like the 128 spectrums). There are plenty of advantages to running directly from ROM if you can and self-modifying code is really the only reason not to.

[Bryce]

That's me just displaying my lack of software knowledge I didn't know you could shift the screen somewhere else.

@TFM: Couldn't that be done on the ROManger software so that it could display something sensible like a progress bar and a message about the switch position? Instead of the data you see at the moment when writing.

Bryce.

[TFM]

Oh, well I guess Bryce is pretty right about screens - if it shall run on a 464 too.


Details... we got four blocks of RAM, and for a smooth game, you probably use double buffering. Means you need two screens, right?


Block 0000-4000: Contains the RST vectors, you can't use them when putting a screen there.
Block 4000-8000: Can be used as screen, if you don't bank. It also contains the 6128 Plus's memory mapped IO.
Block 8000-C000: Only common RAM block for all configurations, so it shall contain the stack
Block C000-FFFF: Can contain one screen.


Now using &C3 RAM configuration banks the screen from &C000 to &4000, BUT this only works on 6128 machines, not on 464/664.


Solution: Only blocks beginning at &4000 and &C000 can be used for screens. (ok, maybe &0000 too, but then you got NO RST commands and NO Interrupt Mode 1 working!)


So yes, writing from ROM to screen RAM is tedious. You do need routines in RAM.


Now if you put only few routines in RAM (either for writing to a screen at &C000 or for selfmodifying routines) then you just DON'T HAVE a program running in ROM!

[TFM]

@TFM: Couldn't that be done on the ROManger software so that it could display something sensible like a progress bar and a message about the switch position? Instead of the data you see at the moment when writing.

To write to the Megaflash you do need to write either to &8000-&BFFF or to &C000-&FFFF, right?


If a write to &8000-&BFFF works, then yes, it can be done. Alternatively: the screen RAM could be moved to another location and the progress bar could be displayed there.
At the moment the filling of the screen RAM serves as progress bar