The new fork of HuC

[Arkhan]

Hnmng.    I'm still using HuC 3.21 from 2005 (The one where the mod player will be released next week).

It generates some pretty goobery code from what I recall when you do alot of array usage within If/Else stuff.  .   

You can optimize that stuff like mad if you just convert it yourself.... and most of the time, game code is not really that complicated, so it's not that much work.

The library and such is why using HuC is still an OK idea.  You just need to get used to the idea of having to do assembly.

honestly, if you don't want to do assembly, you are f*cked, more or less.

Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.

[spenoza]

Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.

Well, as homebrews go, Atlantean is a pretty attractive, smooth-operating game, and I'm not at all surprised that was necessary to make it like that. That said, for Gredler and DK, having a robust HuC implementation allows them to get their feet wet making a game which may be compromised in some ways, but is still functional. And as their abilities improve, they can slowly start learning to insert ASM to replace some of those C functions. But the easier it is to work with HuC and still get acceptable results, the more likely they are to keep at it and develop those skills.

[Gredler]

Most of Atlantean simply turned into C entry points that were full of giant #asm blocks of what used to be C code.

Well, as homebrews go, Atlantean is a pretty attractive, smooth-operating game, and I'm not at all surprised that was necessary to make it like that. That said, for Gredler and DK, having a robust HuC implementation allows them to get their feet wet making a game which may be compromised in some ways, but is still functional. And as their abilities improve, they can slowly start learning to insert ASM to replace some of those C functions. But the easier it is to work with HuC and still get acceptable results, the more likely they are to keep at it and develop those skills.

Well said, and true, if it weren't for HuC's approach-ability we would not be making our project. When I met DK I showed him HuC and he has taken the reigns since then doing 100% of the coding. I hope to help and do some stuff eventually, but as it stands right now I haven't even seen our code.

[Bonknuts]

Well, maybe some peeps can do a basic ASM tutorial geared directly for HuC. Starting with pretty simple optimizations and usage of ASM, and move to more advance stuffs.

 A tutorial on how to do benchmarking (which should be super simple), should be included.

 I'm just throwing ideas into the fish bowl...

[Gredler]

Well, maybe some peeps can do a basic ASM tutorial geared directly for HuC. Starting with pretty simple optimizations and usage of ASM, and move to more advance stuffs.

 A tutorial on how to do benchmarking (which should be super simple), should be included.

 I'm just throwing ideas into the fish bowl...

Very much appreciated ideas, I can't speak for DK but performance profiling, bench marking, and resource tracking seem to be non-existent. Debug options in modern engines are what have spoiled me the most, I would say.

[Arkhan]

I benchmarked Atlantean by writing an FPS counter basically.

You can also print stuff into the overscan area and see what routines take the longest (this is a common thing).

Sometimes, you might spend time optimizing useless crap, so it's best to optimize the most often-called things first.

[Bonknuts]

Sometimes, you might spend time optimizing useless crap, so it's best to optimize the most often-called things first.

I agree. Throwing ASM at everything, isn't necessarily going to net you much.


 It's not just speed, in making your code faster, but in the context that if you have faster methods - you might be able to user more advance concepts. Better design, etc.

 Uhm.. let me see if I can think of an example. Animation is one area. Not the animation cells them selves, but how you interface with them. You could just use fixed code branches that handles most objects, but as processing resource increased as game and arcade systems advanced, the use of multiple layers of indirect of data types allows for more flexibilty in design. Even some NES games use this, to some degree. It allows you to make changes to the game design, without modifying a lot, or any, code. It also might allow for more advance or precise definitions related to timing and response of objects.

 The data structure might look something like this:
 Frame-> has attributes: meta cell patterns, X/Y offsets, duration of frame until next, etc and the length of this set (because the data elements could be variable in number/size).
 The frame would be part of a larger definition, such as walk, run, jump, attack, etc. So through a series of table of pointers and indirection, data/definitions are accessed and objects are built. Simply pointing to a different data structure builds different objects. If I were to do this entirely in HuC, it would be pretty slow. I could circumvent it by building sets of code to directly handle specific objects, but then you lose flexibility in design and changes, etc. Object behavior/reaction/AI/logic can be handled in the very same way, with layered data structures that eventually points to code as well.

 This is how I've done my stuff. Even in ASM, I trade a little bit of performance for flexibility. I'll cheat in areas where some objects are simplistic in design, so I'll use simpler code paths, but ultimately I want to use external tools to create complex objects (enemies, events, whatever).

 The problem inherent in HuC, or at least 3.21, is that pointer use is fairly slow. The other problem is that language structure itself is expecting some instances or forms recursion (whether you make a recursive function or not), so there is a lot of internal (software) stack manipulation. The two together, really bog down the processor in its current implementation. Learning a little but of ASM, and how pointers work, can save a lot of performance itself - but it can also allow for more complex design like I (tried to) demonstrated above.

 tl;dr  - Speed isn't just speed. It's also translates into other things. You might say, "my game runs fast enough". And that would be fine. So maybe that speed translates into something else; more complex or capable and flexible game and code design?

[Gredler]

The data structure might look something like this:
 Frame-> has attributes: meta cell patterns, X/Y offsets, duration of frame until next, etc and the length of this set (because the data elements could be variable in number/size).
 The frame would be part of a larger definition, such as walk, run, jump, attack, etc. So through a series of table of pointers and indirection, data/definitions are accessed and objects are built. Simply pointing to a different data structure builds different objects. If I were to do this entirely in HuC, it would be pretty slow. I could circumvent it by building sets of code to directly handle specific objects, but then you lose flexibility in design and changes, etc. Object behavior/reaction/AI/logic can be handled in the very same way, with layered data structures that eventually points to code as well.

This sounds like how it would be done in a lot of modern object oriented applications, and seems to make sense if I am understanding you correctly. Catastrophy has some complicated animation stuff we're doing, I wonder if there are big performance gains to be had there (or like you said, more we can do - like in terms of contextual animation)

[dshadoff]

There are other things to consider when writing C on a small machine like this.  You need to understand how C works, if you want fast code.

For example, let's ignore pointers and arrays for a minute, and talk just about scalars.

1) You should know that local/automatic variables are generally allocated on a 'stack' - on any machine.  But on this machine, the stack is slow.  So, local variables = bad.  Global variables = good.

2) Parameter-passing.  This is also done through a 'stack'.  But they also need to be packed (by the calling function), and referenced/unpacked (by the called function).  On this machine, the stack is slow.  So parameter passing is something to be avoided too, where possible.  Again, substituting with globals is preferred (where possible).

You will notice that assembly-language programs from the same era also do these same two things... sometimes the globals are in zero-page, and sometimes outside of it.

Trying to use 'modern' programming principles throws away CPU cycles - cycles which aren't considered a big deal on modern CPUs, but cycles which were precious in the 8-bit era.

-Dave

[DarkKobold]

Here's the thing about our game - its separated into chunks. The only real complexity comes from the number of "modes" the game has. Each boss has its own "player control" function, so I can tweak how each part of the game handles. I like it that way.

Thus, my code lacks flexibility. Once the player control code is copied and pasted into a new boss, any changes have to be done to each function, rather than across the board. That said, each boss should control differently. All in all, the code is fast enough, and simple enough, that I don't need any extensive clean-ups, or switches to ASM. Thus far, there is no slow down. The real limitation we are going to run into is ROM space. If a new fork of HuC made the best use of ROM space, or wrote smaller ASM from C, that would help in the long run.

That, and not having a sound guy. We still don't have a musician/sound effects guy. Our game is still mute, for the most part. That is a far bigger downfall to the game, than anything with the current speed of the code.

[Gredler]

That, and not having a sound guy. We still don't have a musician/sound effects guy. Our game is still mute, for the most part. That is a far bigger downfall to the game, than anything with the current speed of the code.

As great as squirrel is, trying to get guys to use it has been like pulling teeth. The only sound in the game so far (and anytime soon, it's looking like) has been made by me with a C- programming knowledge, and a F- music/sound knowledge Castastrophy might sound catastrophically bad

[Bonknuts]

Here's the thing about our game - its separated into chunks. The only real complexity comes from the number of "modes" the game has. Each boss has its own "player control" function, so I can tweak how each part of the game handles. I like it that way.

 Well, I was just using one example. There many other examples as to what ASM can translate into besides just speed. But it sounds like space is the only real issue you have for this project.

Thus, my code lacks flexibility. Once the player control code is copied and pasted into a new boss, any changes have to be done to each function, rather than across the board. That said, each boss should control differently. All in all, the code is fast enough, and simple enough, that I don't need any extensive clean-ups, or switches to ASM. Thus far, there is no slow down. The real limitation we are going to run into is ROM space. If a new fork of HuC made the best use of ROM space, or wrote smaller ASM from C, that would help in the long run.

 Typically, code is much smaller than data for game projects. Of the roms and such that I've traced through on the PCE (hucard and CD), code is typically 32-40k. Data, tables, sprites, - anything data is much larger part of the game.

 Maybe you can save some space by compressing your graphic data (specifically, tiles and sprites). You don't need ASM to do that, and it doesn't even have to be fancy like LZSS, etc. Thought that means you'll need to have to create your own pcx or bmp conversion tools.

 I have some pics somewhere that I can post, showing visually what I mean (and how much it safes). Should be easy to write the decompressing code (that writes directly to vram) in C too. No ASM.

 Stuff like using mappy 16x16 format saves on tilemap size, but it doesn't use a LUT for the tiles in the 8x8 segments of the meta-tile. Depending on your tileset, there could be a lot waste just in redundant 8x8 tiles inside the pseudo 16x16 set. Also, there's no simple RLE or column/row/token reference compression for the map data either, etc - but depending on your game, tilemap data might not be that big to begin with.

 As for code, have you tried stripping out stuff in the library that you don't need? Like the pixel draw routines and such?

[Gredler]

Maybe you can save some space by compressing your graphic data (specifically, tiles and sprites). You don't need ASM to do that, and it doesn't even have to be fancy like LZSS, etc. Thought that means you'll need to have to create your own pcx or bmp conversion tools.

 I have some pics somewhere that I can post, showing visually what I mean (and how much it safes). Should be easy to write the decompressing code (that writes directly to vram) in C too. No ASM.

 Stuff like using mappy 16x16 format saves on tilemap size, but it doesn't use a LUT for the tiles in the 8x8 segments of the meta-tile. Depending on your tileset, there could be a lot waste just in redundant 8x8 tiles inside the pseudo 16x16 set. Also, there's no simple RLE or column/row/token reference compression for the map data either, etc - but depending on your game, tilemap data might not be that big to begin with.

Thanks I would appreciate all the info I can get to become more efficient with art generation. Is the data size of the pcx file unrelated to its impact on the footprint on the rom size?

As an artist, besides just using less tiles and less sprites, is there something I can do to help? Currently our tilemaps are pretty danm big, if I recall the shower scene is a 256x192 or so. Our sprites are large too, the vacuum is 64x192.

[Arkhan]

Compressing graphics is a thing.   Or if you're using CD, you can just load them as you need them.

As for Squirrel, were your dudes having problems with it?   I really don't think you will find an easier way to get SFX and music going in your game.   The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.

[Gredler]

Compressing graphics is a thing.   Or if you're using CD, you can just load them as you need them.

As for Squirrel, were your dudes having problems with it?   I really don't think you will find an easier way to get SFX and music going in your game.   The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.

Thanks for the help senior, very appreciated!

We are trying to get this thing on a hucard, so CD is not an option for our rom size and graphical woes - compression sounds necessary!

The guys I've reached out too seem to have trouble comprehending the midi to squirrel process; be it limited channels or cleanup they really seem to have a hard time with it. These dudes are just people who have ability to play instruments and limited ability in coding, no real development knowledge.

Can you provide some freeware examples of DAWs? Right now it looks like if I am not doing the music and sound than I will be training the person who will, and right now I just code everything in MML by hand, resulting  in the atrocities we call music in our game. If I had a tool to compose with it would level up a tiny bit, and might help me be able to get someone with actual ability to work on it by bridging the disconnect between typical music generation software and squirrel.

My good friend who wants to develop games with me was the prime candidate for our musician, and his software of choice is "renoise" which in my inspection seemed to be overkill and excessive for our needs, so a simple common documented equivalent that we don't have to invest funds in for a license would be most helpful!!