The new fork of HuC

[TurboXray]

https://github.com/uli/huc

 So is anyone interested in using this?

On a side note:
 I downloaded the source and tried to compile it under gcc using code:blocks, but it errors out on fmemopen() reference. I looked it up, and according to gnu it's part of stdio.h (gnu.org/software/libc/manual/html_node/String-Streams.html). But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?

Update:
Commenting the fmemopen reference...

Code Select Expand

/*if (!data)
data = fmemopen(data_buf, DATABUFSIZE, "w");
if (!rodata)
rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
    */
And it compiles without problems. Just need to figure out how to re-implement fmemopen in mingw.

[elmer]

But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?

Presumably because it's of limited practical-use, and can be replaced reasonably-easily where it has been used ... which it obviously isn't in the hundreds of packages that mingw-w64 does support.

It was a bit lazy of Uli to use it, but he did, and now it's up to someone else to fix it if they don't want to compile under cygwin on Windows.

It's just being used to buffer and rearrange different sections in the HuC output. That's something that Uli added, and it wouldn't be too tough to implement the same functionality in a different way that didn't need fmemopen().

BTW ... I'd recommend using Artemio's fork-of-Uil's-fork rather than Uli's version. Artemio fixed a few things after Uli stopped working on it.

You may have missed my cygwin build of it here ...

HuC - Newbie questions?
https://www.pcengine-fx.com/forums/index.php?topic=21136.msg461615#msg461615

It's definitely a little better than the old HuC ... but not leaps-and-bounds.

To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.

HuC was wonderful for its time ... but it's architecturally hamstrung because of its Small C origins.

Eric Petrich (the SDCC developer that I've been working with) recently "went public" and created a new SDCC branch in the main SDCC codebase on SourceForge for the new 6502 compiler port.

Since he's actually one of the main SDCC developers ... that means that it's all going to eventually get rolled into the main SDCC codebase when it's finished.

But, to be honest, I've haven't been as active as I should be in helping him get the SDCC port done.

It's my current task to add 6502 support to the ucsim simulator that's going to be used for automated-testing of the 6502 port, but I've been too busy with the Xanadus, and PC-FX GCC, and now in preparing to disappear into the desert for a week.

IMHO ... if you want to take the time to try to improve C on the PCE, then may I suggest that you consider helping out the SDCC port rather than applying yet-another layer of small fixes to HuC?

[TurboXray]

To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.

Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.

[Sunray]

I've used it for about a year now. I use Cygwin for compiling and you can use the compiled exe without Cygwin later, just need to have a cygwin dll copied alongside the exe files.

I would not have started doing PCE homebrew without this fork.

[DildoKKKobold]

So, I'm using "vanilla" HuC. The thought of having to install Cygwin to compile a new version of HuC sounds less fun that punching myself in the nuts. What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)

Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM. I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.

[touko]

I can't think of anything less fun than writing 6502-style ASM

Hu6280's asm is fun, really 

Huc is really fun to start with PCE coding, but it shows it's limits quickly .

[elmer]

Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.

One of the best aspects of HuC is that it's a simple-enough compiler to "play" with.

You might also consider modifying LCC, if you want a well-documented (there's a book) C compiler to play with.

I've got to say that I found the SDCC code to be incomprehensible to me. 

What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)

A whole bunch! 

ANSI C syntax instead of the horrible old K&R syntax is the most immediately-obvious.

Just look at the README in the link that Bonknuts put in the 1st post in this thread.

I would not have started doing PCE homebrew without this fork.

Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM.

Comments like these show that there's a desire for a C compiler for PCE development, and HuC has been wonderful for that.

It's just that there are much better open-source compiler front-ends available these days than Ron Cain's Small C, and it should be possible to generate much better 6280 code than HuC can ever be "fixed" to generate.

Until that happens, HuC (or Uli-fork-with-Artemio's-improvements) is the best option for folks.

[Sunray]

Clang + LLVM backend for Hu6280 would be optimal. HuC works fine for me but a better compiler would mean more advanced homebrew.

In my homebrew game the game code is cross platform and the PCE backend is a mix of HuC + asm. I plan to port it to Amiga and SNES in the future (if I ever finish it). Without C this would not be possible.

[TurboXray]

Been trying to make sense of fmemopen and how it's used. I think I got this figured out. It'll be kind of a hack, because how he reused functions pointing to file streams instead of buffers, but I could change data and rodata to actual fopen(). There's a point where data and rodata get fclose() and just the data from the buffer is transferred to the main output stream (output) - this is in dumpfinal(). This could be changed to a simple read the file contents back into the buffers, then pass those buffers along.

 No where else is fmemopen() used except in main.c and in the global definition section dumpglbs().

 That, or where everything eventually gets routed to a single fputc() output, a little bit of conditional code to handle writing directly to the data/rodata buffers upon detection. Either should work and remove the cygwin dependency.


 Note: Not that I write the most beautiful code, but goto and continue usage seems.. I dunno, out of place. Feels hack-y/rushed in code design instead of thought out. I shouldn't criticize, really. But it is strange to see it there.

 Edit: Meh.. I'm just gonna rewrite *buffer version of all the fstream functions. There's not that many. It'll be more readable.

[TurboXray]

More Posix specific stuff that's not in mingw (lock and unlock stuffs for File streams), but this time in pceas.

[TurboXray]

OK. I got HuC compiled with the changes and removal of fmemopen. It compiles a simple source file, but pceas is complaining that it can find the x86 pseudo reg names (they now have an underscore). This looks to be a backend lib thing and not a executable issue (there were notes mentioning of moving and changing the asm lib stuffs).

 Elmer, is that link from your drop box Artemio's fork?

EDIT: Nevermind about the x86 pseudo reg issue. Seems to be from add32() fastcall that's internal to HuC. No one bothered to change the names of the pseudo regs for the internal fastcalls to the match the changes to the backend lib. I'll update those now in HuC source code.. I'm not even sure why there are even internal fastcalls. Those should all be in the library..

 Here's the modified main.c for mingw
(edit: I'll upload it as complete source package and binary snapshot once I get enough testing done. So far, so good.)

[elmer]

OK. I got HuC compiled with the changes and removal of fmemopen.

Excellent! Congratulations! 

Elmer, is that link from your drop box Artemio's fork?

Yes,  the build that I made was from Artemio's github fork.

Good luck! 

[TurboXray]

Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else). They even submitted the changed files (trap did switch case extension to 256 levels, and re-wrote code for pcxtool - needed for dealing with photoshop's PCX format). Artemio's pull request was just for PCEAS and better bank sorting. Did he touch HuC at all? Did he have a git page?

[TurboXray]

Update: Just testing out some features of the 3.98 HuC build. Seems const arrays can be populated during compile time, but variable arrays can not be populated during runtime. But that's not the issue per se; it's how HuC is handling the error messages. It's hard locking the program.

 I'm gonna run the compiler through the gnu debugger with PCE C source files known to cause HuC errors, to see what's happening.

 Update2: Wow! Looking at variable array direct access and it's fast. Very nice. Pointer into array isn't that bad either (IIRC it was treated as far access in HuC 3.21, not so in this release).

 Update3: I'm looking at the code generation for pointers and arrays, and I'm pretty happy with the improvement. Though there's one thing that could be improved further; if the index into an array pointer (if char *x, then x=array, x[i ] =0) is smaller than 256, it should be indexed by Y instead of added to the pointer manually (it's a 16bit add regardless of the value for the code generation).

[elmer]

Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else).

When you're on Uli's github web page, just click on the number to the right of "Fork" near the top of the screen.

That'll take you to the revision graph. You can click on any of the different fork's revisions on that graph and it will take you directly to the github page for that fork/revision.

That's the easiest way (that I know of) to get to Artemio's page from Uli's page.

[TurboXray]

Ahh thanks! I'm not familiar at all with github, so just now getting a chance to explore it/figure things out. It's actually pretty decent idea.

Also, having some fun testing out new features:

Code Select Expand

#include "huc.h"
#include "string.h"



struct BMP {
  int height;
  int width;
  char name[10];
};

struct BMP bmp;
struct BMP png;
struct BMP *bmp_ptr;

main()
{
 
  set_color_rgb(1, 7, 7, 7);
  set_font_color(1, 0);
  set_font_pal(0);
  load_default_font();
  disp_on();
  cls();
 
 
  bmp.height = 1;
  bmp.width = 1;
  strcpy(bmp.name, "test");

  put_string(bmp.name, 8, 5);

 
  bmp_ptr = &bmp;
 
  bmp_ptr->width = 256;
  bmp_ptr->height = 192;
  strcpy(bmp_ptr->name,"Ginger");
 
  put_string(bmp.name, 8, 6);
 
  bmp_ptr = &png;
  bmp_ptr->height = 32;
  bmp_ptr->width = 32;
  strcpy(bmp_ptr->name,"Bonk");

  put_string(png.name, 8, 7);

  bmp_ptr = &bmp;
  strcpy(bmp_ptr->name,"test2");

  put_string(bmp_ptr->name, 8, 8);

 
  while(1){};
 
 
  return 0;
}
 Note: I'm also looking at code improvements. The compiler sometimes optimizes for values kept in A:X, which is decent, but then there are occasions like temp++; which loads a 16bit value of temp (which is a char) into A:X, but then does a simple inc temp following it.

 The other thing that bothers me, is that all 8bit values being extended into 16 values (A:X) are done at runtime instead of compile time, if the variable is signed. Because the compiler is doing this automated extension, it also means signed extension has to be handle at runtime. This means unsigned vars will always be faster than signed - for chars. If compiler didn't automatically extend everything into 16bit, this wouldn't be a problem. So this is an area where the compiler still needs work. I mean, unsigned char is just one extra byte and 2 extra cpu cycles (cla).

 In other words, the compiler is automatically type casting every char. It shouldn't. There should a specific set of build-macros just for handling char values (I think Dave Shadoff was working on this as an optimization switch in the 3.21 version).

[TurboXray]

I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.

This got me thinking. So, do you have any ASM mixed into your C code? Would you be willing to use some generic, easy to use ASM template code if it was given to you in tutorial form - to mix with C?

[OldRover]

Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'.

[spenoza]

Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'.

Can you blame folks for wanting better? The tools folks use are important to them.

[DildoKKKobold]

I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.

This got me thinking. So, do you have any ASM mixed into your C code? Would you be willing to use some generic, easy to use ASM template code if it was given to you in tutorial form - to mix with C?

Um, absolutely, if it helps the program. That said, I'm not sure what you could provide, since that is really the job of the compiler, right?

[OldRover]

Can you blame folks for wanting better? The tools folks use are important to them.

No way! Never once in the 13+ years I've been using HuC have I ever thought "you know what? it would be nice if this was more efficient and I didn't have to longform certain techniques just to get good speed out of them at the expense of code size"... never once crossed my mind!

[TurboXray]

That said, I'm not sure what you could provide, since that is really the job of the compiler, right?

Speed.

 In the form of small copy/paste segments of asm code that you simply replace the variable name.

 Anything else, like added complexity, and you'd just have to learn ASM yourself to implement it.

Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'.

It wasn't aimed at asking HuC vets ;) Funny though, but I haven't seen you guys post anything public about it, specifically. Or did I miss something? Exclusive club?

[OldRover]

Funny though, but I haven't seen you guys post anything public about it, specifically. Or did I miss something? Exclusive club?

Perhaps because these solutions are usually specific to the implementation and don't have general application. Either that or we just converse in secret, keeping all of the secrets of the universe to ourselves.

[TurboXray]

Illuminati!

[esteban]

If only the Illuminati would release the PC Cocoron ISO.

[elmer]

Can you blame folks for wanting better? The tools folks use are important to them.

Having a compiler that barely-qualifies as recognizable modern-C, and that requires you to perform all sorts of undocumented and hidden gyrations in order to work around its limitations ... is not very user-friendly.

IMHO, it should be possible to do better these days, and have a compiler that produces "just-about-acceptable" code that's no more than 2 or 3 times slower than pure hand-optimized assembly language.

The work that Uli (and Artemio and the others) have done has been a big step forward in making HuC more usable for modern folks, and I hope that people will take advantage of it.

I just know that a better compiler is possible, and that it could help people.

But it doesn't replace the desire or passion of dedicated homebrew developers, who will work long hours to create something fun on the PCE with whatever tools are available.

Arkhan and I have been finding ways around HuC's limitations for years now. Just sayin'.

And as Arkhan has said himself ... he basically prototypes in HuC, and then when he's got the logic flow written, he rewrites large chunks of C code in pure assembly.

That shouldn't really be necessary ... or at least be something that's confined to a few specialized functions that get called lots of times per frame.

No way! Never once in the 13+ years I've been using HuC have I ever thought "you know what? it would be nice if this was more efficient and I didn't have to longform certain techniques just to get good speed out of them at the expense of code size"... never once crossed my mind!

Good for you! 

For me ... I looked at language limitations and the code that it produced and said "I'd rather be writing in assembly".

[TurboXray]

Having a compiler that barely-qualifies as recognizable modern-C, and that requires you to perform all sorts of undocumented and hidden gyrations in order to work around its limitations ... is not very user-friendly.

IMHO, it should be possible to do better these days, and have a compiler that produces "just-about-acceptable" code that's no more than 2 or 3 times slower than pure hand-optimized assembly language.

The work that Uli (and Artemio and the others) have done has been a big step forward in making HuC more usable for modern folks, and I hope that people will take advantage of it.

I agree. And not just modern folks, but the whole idea of a higher level language environment is to avoid dedicating years of experience with assembly targeted for said platform. It seems ridiculous that programmers should have to fight the compiler the whole way through, such as HuC, when there are much more similar and mature language products.. on similar spec'd platforms.

 I know the 65x arch isn't the best design for efficiency for something like C, but that isn't the whole excuse. HuC, version 3.21, I wouldn't even call it "small" C.. I'd call it "barely" C. I'm not bagging on it for not being more than what it was (Dave Shadoff even described it as being an introduction to PCE programming and nothing equating seriousness). To me, that implies "novice" and "toy". But that doesn't mean both functionality (support for more modern concepts and constructs), and speed/efficiency can't be brought up quite a few levels. I find the upgrades that Uli has done to be quite staggering by comparison (you don't get a full picture until you go through the hundreds of test files in the PCE C test source folder, showing off new functionality).

 I admit my motives might extended beyond just the benefits of the PCE, but I find the platform a comfortable choice since I know it so well; I'm interested in both compiler work and implementing different programming concepts. That said, I'm actually kinda excited to do a C project for the PCE with the new changes/upgrades. This.. coming from an assembly-to-the-core guy for PCE. Heh.

[dshadoff]

If you really want to talk about high-level programming, then even more important than the compiler is the set of libraries and base functions which are available to the programmer out-of-the-box.

HuC implemented many things which had not been attempted or available before - and were developed as part of the work of HuC:

Such as:

- CD-ROM boot (and a dual-boot option which some had thought was not possible)
- standard hooks into the CDROM card (including documentation), and replacements of most functions for HuCard builds
- more access to the VDC than had been available previously
- an integrated font and print functions (not just POSIX streaming to a termnal device)
- access to backup ram functionality
- PCE mouse functionality
- a clock timer
- random number generator
- a standard set of IPL routines (including initialization to various resolution modes)
etc.

A lot of work went into this functionality which could have otherwise been spent on the compiler - but then the compiler would have been even less useful.

While you work on the newer compiler, please keep this in mind and consider the libraries - which would by definition be hand-optimized and the best code available - and make a lush set of building blocks.  If done properly, this could reduce reliance on the code generator for speed and efficiency - and on the language itself for ease-of-programming.

Please be my guest to use what exists in HuC, and build on it where it makes sense.

-Dave

[Arkhan Asylum]

I never posted anything publicly for assembly optimizations, because it's simply hand-converting C code to 6502 assembly.

If you don't know how to do that, me pasting it to you isn't going to help, lol.

It came up briefly in that other thread.   

It's as simple as accessing arrays using 6502 assembly.   That's something any 6502 book will show you, fairly simply.

and then If/Else is just converted to compare/branch code.     Simple, really.    Just find a 6502 tutorial and read how to do compares and indexing.

It's not really a mind blowing process.   It's more like mind numbing.   

The compiler, even if it were to be improved over HuC, would still be a bit goony with regards to doing efficient array usage in something like:

Code Select Expand

if(thing[i] > thingy[i]).
You could make it smart about the generation of stuff, but then it adds alot of complexity to how you generate that code.


Hand converting functional C code to 6502 is OK by me.   It's a great learning experience, and a great encouragement to convert to using z80 instead.

6502 is mental.

lol

[TurboXray]

The compiler, even if it were to be improved over HuC, would still be a bit goony with regards to doing efficient array usage in something like:

Code Select Expand

if(thing[i] > thingy[i]).
You could make it smart about the generation of stuff, but then it adds alot of complexity to how you generate that code.

HuC 3.98 code generation isn't too bad:

Code Select Expand

__ldub _arr1+1
__pushw
__ldub _arr2+1
  jsr gt
__ldub is just ldx $abs and then a "cla", which is pretty fast. __pushw is a bit ugly since it uses the larger stack by default, but Uli has working optimization switches which use a much faster internal stack method in the code generation. At least the array access is fast.

 Dshadoff: That's a great point. Sometimes I forget just how much work was put into the library for HuC.

[Arkhan Asylum]

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 fucked, 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.

[TurboXray]

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 Asylum]

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.

[TurboXray]

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

[DildoKKKobold]

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

[TurboXray]

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 Asylum]

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!!

[spenoza]

Can Deflemask output to MIDI? The only reason I ask is that it is commonly used to craft "chiptunes" using classic samples. There are a surprising number of folks out there who work in chiptunes who only know how to use trackers, and having a path for them to get to Squirrel might be helpful.

'Course, if your friend is a legit musician, just generating something in MIDI is probably a lot easier.

[Arkhan Asylum]

3MLE is a MIDI piano roll program for free.  That's your best bet.

[DildoKKKobold]

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.

Squirrel is awesome for getting music and SFX into the game. It works great, at least from the coding side.

The biggest key has just been finding someone willing to actually make the music and SFX for us.

[Gredler]

None of the guys I've tried to get involved seem to have given it a fighting chance, to be fair too. I am going to try using 3MLE to make something, and maybe it won't be so abrasive.

[Arkhan Asylum]