Author Topic: Game ROM library  (Read 612 times)

0 Members and 1 Guest are viewing this topic.

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Game ROM library
« on: 07:51, 21 June 21 »
I was thinking... we have AMSDOS, and in fact such a powerful extension mechanism for CPC with ROMs...


If a game library ROM was created somewhat like laser basic but without the himem issues, for use with BASIC or machine code games, would have more RAM for the game since sprite, tiling, music routines and anything else that games developers laboriously task away at... what would be the cons of having all the best routines always there in ROM?
« Last Edit: 09:12, 21 June 21 by zhulien »

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: Game ROM library
« Reply #1 on: 10:24, 21 June 21 »
Here is a short list for some ideas to kick it off.  A game would require a minimum ROM version and if a later better ROM version is available, the game would hopefully just get better because of improved ROM code... some of the code I have already coded for other projects so just a matter of pulling it together, other bits of code better programmers can contribute where my coding sucks.



Hardware support for not via drivers at this stage, but via monolithic configuration:


- standard CPC (of course)
- CPC Plus features (sprites & audio DMA)
- expansion RAM up to 4mb
- Multiplay
- Playcity
- SSA-1, dkTronics, Llambaspeak
- AMDRUM, Music Machine
- UART MP3
- Mass storage




(compatability)


- v1: usable with locomotive BASIC
- v1: usable with machine code games
- v1?: usable from within CP/M? (is there a point?)


(file support)


- v1: loading of assets (from whatever filesystem is there) (utilising firmware)
- v1: loading of memory pages (from whatever filesystem is there) (utilising firmware)
- v1: loading of settings from a config file (global & game-specific) (utilising firmware)


(memory)


- v1: support for memory compartmentation: asset memory, game memory etc for easier support for virtual memory*
- v1: support memory handling (64kb up to 4mb) with Linked Lists to handle data structures that we do not require super-fast access to.
- v1: packing functions to pack linked list structures into arrays (linked list to array), possibly the opposite also (array to linked list)
- v1: fast memory movement


* allows a single set of simple logic to pack linked lists into arrays regardless of real memory capacity, just slower with less real RAM (but M4 SDCARD and X-Mass are pretty fasts for a CPC)


(tasking)


- v1: basic multithreading support


(input)


- v1: keyboard input (utilising firmware?)
- v1: joystick and mouse support including with multiplay support for up to 4 joysticks or 2 mouses


(screens)


- v1: multiple (virtual) screen support
- v1?: configurable screen size
- v1?: overscan support


(sprites)


- v1: multiple sprite routines with automatic but controlled animations
- v1: multiple controlled collision detection methods
- v1: sprite/tile maps
- v1: software scrolling and hardware scrolling options (maybe CPC Plus scrolling?)
- v1: CPC Plus hardware sprite support with software fallback


(audio)


- v1: DAC (8bit 3 channel DAC support with preprocessing to current hardware for 2.5bit support / 6128 Plus hardware support if possible)
- v1: speech (ssa1, dkTronics, llambdaspeak)
- v1: UART mp3 start/stop etc
- v1: up to 9 channels of AY sound effect support (playcity support and internal)
- v1: up to 9 channels of AY music support (playcity support and internal)
- v1?: SID sound effect support
- v1?: SID music support



(internet support)


- v1?: achievements via 8bitology.net




FUTURE:


(non-sprite graphics)


- drawing primitives (2d and 3d vector?)
- image transitions


(crunching)


- maybe...


(internet support)


- multiplayer games


...




Any suggestions?


Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.003
    • Awards
Re: Game ROM library
« Reply #2 on: 11:10, 21 June 21 »
I suspect the problem with trying to do this is you either have to reserve large amounts of RAM for every function the ROM provides (even if you don't use it) or handle everything via indirections (which takes a performance hit).


It might work better in an AGD type scenario, where all games are essentially being run on top of a shared game engine but I'm not sure you can easily extend it to generic M/C games. 8-bit software just relies too heavily on heavily optimising key structures.


Putting entire games on ROM (either via CPR or some other cart style arrangement) seems like a more workable solution to me.

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: Game ROM library
« Reply #3 on: 11:33, 21 June 21 »
I suspect the problem with trying to do this is you either have to reserve large amounts of RAM for every function the ROM provides (even if you don't use it) or handle everything via indirections (which takes a performance hit).


That is where the memory compartmentation comes in, we can for example say we have 2 banks of 'live assets' and n banks of 'available assets'.  To make the game fast we make the live assets from the available ones by packing them from the asset list.  They can be just read as required, but if you have already a massive asset list we can have a simple function (from the game programmers point of view) that iterates through all the available assets taking the ones required for a particular scenario (or game level).


From a performance point of view...


if BASIC that is just an RSX or bunch of RSXs (the fewer the better for himem). 


if machine code, what is the best way? jump direct to the ROM's jumpblock? (why not?) if we define the version and the ROM jumpblock correctly... or if we don't want a jumpblock redirection in the ROM, we can setup the redirection in RAM - or... even have defined fixed points of entry within the ROM - which is fine if they are advertised.

It might work better in an AGD type scenario, where all games are essentially being run on top of a shared game engine but I'm not sure you can easily extend it to generic M/C games. 8-bit software just relies too heavily on heavily optimising key structures.


What is AGD?


The intent would be that there are a couple of optional loops in machine code that can be used by either BASIC or machine code programmers, eg: (all optionally automatic) music, animation, collision detection, character movement, with the game programmer manually doing as little or as much as they require.  Within a game loop, you could argue it is a game engine with optional configurable bits to maximise the performance of a BASIC game, but also allow the most customisability possible from a generic library of functions.


Putting entire games on ROM (either via CPR or some other cart style arrangement) seems like a more workable solution to me.


There is no reason such an accessory ROM which can improve over time cannot also be used for ROM-based games, other than jumping between ROMS is slower than jumping from RAM to ROM (but likely faster than a game with too much BASIC).


I believe that a compromise can be made between ease of use for beginners in BASIC familiarising themselves with concepts such as gameloops, memory usage, background tasks (animation, movement, collision detection, character movement, music)... then when they transition all or part of their game to machine code.


and yep, a gameloop in BASIC will be slower than a gameloop in machinecode always.

Offline eto

  • Supporter
  • 464 Plus
  • *
  • Posts: 435
  • Country: de
    • Awards
Re: Game ROM library
« Reply #4 on: 12:42, 21 June 21 »

what would be the cons of having all the best routines always there in ROM?


So if you're asking for disadvantages of this, I think there could be a few. While I think a library is great and there would be no harm to have a second one besides CPCtelera, I think it should not be distributed in ROM:


- the benefit of a library in ROM is rather small. How much do you anticipate that it reduces the size of the binary? Maybe 4-8KB? Significant of course, but today, unless you are limited to a 464 without extensions, data can be loaded easily in pieces and/or can be compressed - and with the really great productions, you need so much more data, that another 4-8KB will still not help.


- the enduser needs to buy the hardware. Even if it's cheap, probably many won't do it unless many games exist. And for those that would be happy to spend some money, it probably makes more sense to buy a RAM extension, where all 128K games will run, also those, that are not using the library.


- you need someone to produce this add-on. long term. and in quantities.


- there is no "best routine". You can provide a good routine, based on some constraints. But e.g. if the screen size is changed, a sprite drawing routine needs to be implemented differently. So you will always have productions that will not use your library leading to less reason to add a ROM for the enduser.


- updates of the library! You have to ensure backwards compatibility forever. If not, you would break older games (and then developers would stop using it because of this). This limits the progress of the library and/or bloat it.








Offline SkulleateR

  • 464 Plus
  • *****
  • Posts: 465
  • Country: de
    • Awards

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: Game ROM library
« Reply #6 on: 14:21, 21 June 21 »
So if you're asking for disadvantages of this, I think there could be a few. While I think a library is great and there would be no harm to have a second one besides CPCtelera, I think it should not be distributed in ROM:


- the benefit of a library in ROM is rather small. How much do you anticipate that it reduces the size of the binary? Maybe 4-8KB? Significant of course, but today, unless you are limited to a 464 without extensions, data can be loaded easily in pieces and/or can be compressed - and with the really great productions, you need so much more data, that another 4-8KB will still not help.


- the enduser needs to buy the hardware. Even if it's cheap, probably many won't do it unless many games exist. And for those that would be happy to spend some money, it probably makes more sense to buy a RAM extension, where all 128K games will run, also those, that are not using the library.


- you need someone to produce this add-on. long term. and in quantities.


Actually I agree with almost everything you said there, I will have a think about whether the idea could work 'nicely' as RSXs (on ROM) or as a linked library of a type in RAM.



- there is no "best routine". You can provide a good routine, based on some constraints. But e.g. if the screen size is changed, a sprite drawing routine needs to be implemented differently. So you will always have productions that will not use your library leading to less reason to add a ROM for the enduser.


Yes there are different scenarios and just like there would be multiple collision detection methods, there would be different sprite drawing methods.


- updates of the library! You have to ensure backwards compatibility forever. If not, you would break older games (and then developers would stop using it because of this). This limits the progress of the library and/or bloat it.


Another reason a linked library would be better for non-BASIC.

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards

Offline SkulleateR

  • 464 Plus
  • *****
  • Posts: 465
  • Country: de
    • Awards
Re: Game ROM library
« Reply #8 on: 15:11, 21 June 21 »
I would love to see a good "game enhancer" for both Basic and ASM, I always wanted to make something in 8BP but it lacks the english manual and converting the spanish to english with google doesn't make sense in most sentences  :picard:


Of course it would be cool to have it in ROM but for wider availability a loadable .bin would be better for everyone to enjoy those games/software that will be created with it.  ;)

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: Game ROM library
« Reply #9 on: 17:30, 21 June 21 »
I guess assembler source is likely a good compromise, with ability to assembler to RSX (in RAM or a ROM) or exclude bits people don't need when assembled directly.  But... I do like the idea of an external game.bin library which links with any compatible game.  AmigaOS libraries are a fantastic thing and i think something similar but on a much smaller scale could work well on CPC too - maybe... a few libs that are bins that can be swapped in and out... don't want music and sprites at the same time, but want music on the title screen, then maybe they can replace eachother...

Offline asertus

  • CPC664
  • ***
  • Posts: 132
  • Country: es
    • Awards
Re: Game ROM library
« Reply #10 on: 18:39, 21 June 21 »
I would love to see a good "game enhancer" for both Basic and ASM, I always wanted to make something in 8BP but it lacks the english manual and converting the spanish to english with google doesn't make sense in most sentences  :picard:


Of course it would be cool to have it in ROM but for wider availability, a loadable .bin would be better for everyone to enjoy those games/software that will be created with it.  ;)


We must work on that, lets help @jjaranda13 with the translation if he agrees..

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.003
    • Awards
Re: Game ROM library
« Reply #11 on: 18:57, 21 June 21 »
AmigaOS libraries are a fantastic thing and i think something similar but on a much smaller scale could work well on CPC too - maybe...
8-bit machines are much, much more limited than 16-bit machines in this regard. RAM space is incredibly tight and there are only a limited number of instructions that can cope with the level of indirection required to cope with code and data structures at arbitrary locations.


It might work in a BASIC RSX system (where the performance hit is kind of irrelevant), but for performant machine code it just hurts too much. Static linking of assembly routines (where addresses can be fixed at build time) is pretty much the only way to go.

Offline jjaranda13

  • Dev
  • CPC464
  • *****
  • Posts: 43
  • Country: es
    • 8BP (8 bits de poder)
    • Awards
Re: Game ROM library
« Reply #12 on: 21:11, 21 June 21 »
e a good "game enhancer" for both Basic and ASM, I always wanted to make something in 8BP but it lacks the english manual and converting the spanish to english with google doesn't make sense in most sentences 


I promise to do it, I have been delaying it from a long time but I am going to do it. The 8BP library is very mature and complete. My next target is the translation of the 8BP manual

Offline eto

  • Supporter
  • 464 Plus
  • *
  • Posts: 435
  • Country: de
    • Awards
Re: Game ROM library
« Reply #13 on: 22:20, 21 June 21 »
I promise to do it, I have been delaying it from a long time but I am going to do it. The 8BP library is very mature and complete. My next target is the translation of the 8BP manual

It would already be helpful, if the documentation would be available as a webpage instead of a DOC. A webpage can easily be translated with a service like Google translate. The DOC however is hard, as it's too big for most free services. I finally managed to translate one of the latest doc files and I think it then is already good to understand, so maybe this would save you a lot of effort.

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 792
  • Country: au
  • aka Vorax
    • 8bitology
    • Awards
Re: Game ROM library
« Reply #14 on: 10:26, 22 June 21 »
Actually, this is very impressive.



https://www.youtube.com/watch?v=SaS3FCUkPpo