Grind : engine coder needed!

[Tsak]

This is an open call to the community. As the title suggests, we are currently looking for a coder with ASM/C knowhow, willing to help with the development of Grind (https://eab.abime.net/showthread.php?t=115890).
To be specific, here's a list of the most important/base features the engine lacks and what the help is needed for:

• Music support (big priority)[/B] : currently the game does not feature any music (either menus or in-game), so this is also a big priority. The plan is to add MOD support, preferably in P61 format (this was actually supported/tested with the engine long ago, but is no longer there). The proposed configuration is 2 channels dedicated to music and another 2 for sfx. A system for sharing one channel between the two (if that comes relatively performance free) is also welcome though not necessary. In regards to RAM, while there is plenty already available (the projected size per track is 20-40k), it needs to be redistributed/repurposed to dedicate it to music. Note that to add music support, also the sfx system needs refactoring (as it currently occupies all 4 channels and each sfx is custom scripted).
  
• Possible rework of the walls collisions system to eliminate clipping through them (player and enemies).
  
• Split the main menu from in-game, implement a lightweight escape menu: This will give us possible extra ram savings plus open the path for better Menus with their own music and a proper intro.
  
• On demand, dynamic assets loading: Currently all assets used with the included maps are compiled into the executable and are all loaded in memory (at all times). We need to be able to selectively load assets on demand for each map. This is the most important engine feature missing so far and it will require changes practically everywhere, including the tools.
  
• Low level I/O for saves. A password system is already in place but can't be used on 1MB systems (because every asset is compiled into the executable - see above).
  
• Make all necessary changes or additions for the disk version, including compression and possibly splitting the content to multiple disks (if needed eventually).
  

And this is the bulk of the main work(more or less). There are various other, secondary coding tasks planned or required as well, though many of these can already be covered by the existing coding team.

In regards to sources (and as mentioned above) most of the game's logic is in C (using VBCC) while the renderer stuff and core engine is in ASM. The game uses a custom Wad format (maps made in Doombuilder) and comes with a custom tool/interface (and scripts) which is used to setup and compile most of the assets and data, while the final exports are done with Visual Studio. To get a better idea you can also check the Dread source drop here: https://github.com/Krzysiek-K/Dread-source-drop (the Grind source is based on that though closed for now).

Note that we are open to any and all help offers, even for limited tasks in regards to the above list. And since this project is going commercial also expect compensation for your work/trouble (either sharing the spoils from the release or flat payment).
In regards to questions, feel free to ask below and for those interested PM or send a mail to admin@pixelglass.org

[Samurai_Crow]

Just out of curiosity, will the loaders for game assets be required to run from floppy disks or will the OS be allowed to run this as overlay hunks or shared libraries from a hard drive? I know that KK's original code was merciless hardware banging but accessing filesystems gets harder when using trackloaders instead of DOS.library routines.

Edit: I missed this quote:

* Make all necessary changes or additions for the disk version, including compression and possibly splitting the content to multiple disks (if needed eventually).

[DisasterIncarna]

wonder is this is something h0ffman could contribute towards? esp if he was allowed to throw in some show-and-tell on his coding twitch stream like he did with cecconoid/metal gear/etc. obviously 3d stuff might be a headache compared to good old 2d. maybe someone can throw him a query, he certainly ticks the boxes for asm/music.

[Tsak]

Originally Posted by Samurai_Crow

Just out of curiosity, will the loaders for game assets be required to run from floppy disks or will the OS be allowed to run this as overlay hunks or shared libraries from a hard drive? I know that KK's original code was merciless hardware banging but accessing filesystems gets harder when using trackloaders instead of DOS.library routines.

There are both exe (running from HD) and disk versions (adf).
During compiling there are also options whether to kick the system out or not or use the custom trackloader etc.

[Tsak]

Update:

Points below are now taken:
-On demand, dynamic assets loading
-Low level I/O for saves.
-Disc version specifics.

The new coder has also started a general cleanup, plus maintenance tasks for our exports, tool and sources.

So now Music support is the biggest priority item remaining. Any takers?

*New update:

Music is now implemented and seems we can also now tackle all the other remaining points with the current team. Thanks everyone!