What Needs Fixed In Huc?

[OldMan]

Moved discussion from 'MSR is finished" to here.
................

Stuff I would want to see:

-Fix array access (as above)

Dunno about that. No really good way to do indexing, especially with the need to manage pages....
But I'll think on it some more.

-"Auto-backpacking" (as above too)

Please explain. Are we talking about packing the code pages better? It should be doable, but I haven't checked out how pceas (yes, that's where it's done) decides which page to use. I -think- it just uses the current one; to pack them, it might have to insert some mapping code, which could be a nightmare..

-Remove the utterly useless gfx plotting routines (already did this here)
-Remove the broken sound code that just wastes space in hucard building

I'll go one farther. Split the library up so if you need something, you can turn it 'on', and if you don't, you can turn it 'off'. So when you don't need the gfx stuff, you don't get it included.

-Optimize scroll()

I'm shooting for integrating the new magickit scroll first. Optimization is a pita. But possibly we can write a tool to do something like that. (ie, optimizations)

-Better mapper functions that support more than 256 unique tiles
-Getting rid of scan_map_table() and making the mapper support height/width greater than 256

I'm not even touching that, except to possibly make it optional. It should be doable, though.

-Add ACD and SGX capabilities to hulib (Tom did this already)
-Modify compiler/assembler to take advantage of the extra 24KB of SGX work RAM

Don't know anything about the sgx. Probably would be better to clone Huc/Magickit for it, though.

-More intelligent verbose code output (backslashes screw it up at present)
-struct support

Yeah. Not likely, the way the code is set up. Would take some fairly serious work for structs....

-C++ style comments (would help with verbose output, I think)

Have that.

-goto keyword (being forced to do this in assembly is lame)

But then you run into problems jumping to different pages. Besides, my CS professors always told me you don't need to use gotos... and so far, I haven't.

-Expansion of the overlay table (50 is fine until you get serious)
-The addition of a 24 bit variable type for addressing (there's one internally but it's not exposed)
-Much more intelligent use of zero page
-ADPCM streaming (Tom coded one, so I have it in my hulib)

The expanded pointer, I could see. Expanding the overlay table would require a complete re-write of the cd init stuff. (Believe it or not, parts of it have to be in specific places. Especially the overlay stuff, which has a minor bug in it.)

I probably have more but this is about all I can think of for now. I've tried to fix things myself but it's just a nightmare... the code is a mess and things aren't done optimally.

LOL. It started out as a student project, so I don't expect much from it. I would like to do some re-naming of the functions, just so I can figure out wtf is going on.

[Arkhan Asylum]

Dunno about that. No really good way to do indexing, especially with the need to manage pages....
But I'll think on it some more.

I *might* have an answer for that, I'll dig through the book or let you borrow it since I don't have tons of free time til December...

I'll go one farther. Split the library up so if you need something, you can turn it 'on', and if you don't, you can turn it 'off'. So when you don't need the gfx stuff, you don't get it included.

Stop making so much sense!    Removing the broke-as-hell sound code that is in HuC already might be a good idea in the first place though.  If we remove all traces of it and replace it with our proven-to-be-working library, that may be nice.  It will force people to use Squirrel/MML, but hey, tough shit.  It's not like Squirrel and MML are hard to use. 

Don't know anything about the sgx. Probably would be better to clone Huc/Magickit for it, though.

It's basically 2x the PCE. You know alot about it without realizing it, .  There are some super grafx things floating around.  I think wasting time supporting the Super grafx and it's 10 owners who give a damn isn't really worth the effort.   What about you?   There are more pressing things to fix in HuC

Yeah. Not likely, the way the code is set up. Would take some fairly serious work for structs....

Yep, and besides, ghetto-structs work.  Insanity is living proof.

But then you run into problems jumping to different pages. Besides, my CS professors always told me you don't need to use gotos... and so far, I haven't.

I agree, GOTO is the enemy. It doesn't belong in here.  Doing it with ASM if you absolutely need it isn't really hard anyway.  The amount of work spent during all the times youd possibly do it with ASM won't add up to how much effort it'd be to support it in HuC...

The expanded pointer, I could see. Expanding the overlay table would require a complete re-write of the cd init stuff. (Believe it or not, parts of it have to be in specific places. Especially the overlay stuff, which has a minor bug in it.)

It's like a house of cards.

LOL. It started out as a student project, so I don't expect much from it. I would like to do some re-naming of the functions, just so I can figure out wtf is going on.

I'd be willing to go one further with this and document the whole thing better.  The documents out there aren't very good (even has things in it like "Im too lazy / tired / or something to do documentation". 

[OldRover]

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc. And any CS professor that talks about "the evils of goto" is just parroting the same old tired and thoroughly debunked rant from the 70s.

[Arkhan Asylum]

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc. And any CS professor that talks about "the evils of goto" is just parroting the same old tired and thoroughly debunked rant from the 70s.

thoroughly debunked is debateable.  Goto removes the structure of the code and introduces all kinds of hopping around.  It can goon up maintainability.  It's like giving a chimp a loaded handgun.  He might be careful with it, or he might start shooting everyone in the knees.

BASIC is living proof that goto leads to a bad time.  It was a neccessary evil for BASIC.  With C, let the logic pull things around.  Any time you're using goto, there's probably another way to do it that uses no goto.


How often do you really need goto? I can't imagine you needing it super-often to the point where it's becoming so tedious to do that you really need built in support for it, lol.

from the 70s.

You know, he isn't called "TheOldMan" because hes young.

lol.

[OldRover]

It was a bitch to code parts of the menu in MSR without goto support. Without goto, you end up having to do something else instead, and the end result may not be as optimal. And if the generated code ends up being reduced to a jmp anyway, then you might as well just have had goto support in the first place. Say what you will about code readability and hopping around, but the CPU doesn't care about your code readability and it hops around all the time. If you can't follow program flow with goto, then you have other issues to resolve anyway.

A bad coder is a bad coder regardless of what language he's using, what compiler he's using, or what procedures he's using. It's not up to us to dictate good coding form. Some of my code, though it executes perfectly and is highly efficient, would make some CS majors cry... I don't follow any coding standards besides my own, and some of my techniques fly in the face of "accepted good form". Fuck "accepted good form".

But how often do you need goto? I don't know... but you could ask that question for anything, really. Like, when I didn't need the gfx_ procs in hulib, I just cut them out.

About the chimp with the loaded handgun... well, you can apply that to a lot of different scenarios. I remember a similar argument being made when MFC was new... everyone was suddenly afraid of armed chimps.

[OldMan]

Not debating whether goto is a good thing or a bad thing. In the wrong hands, it makes code a mess. In the right hands (which are few and far between), it makes things better. It depends on who is using it....

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc.

First, "just a jump to a label" means you have to recognize the label. As distinct from a leading name. So all that code would have to be inserted.

Second, all labels are global. You CAN jump to a label in another proc. But more seriously, you can jump into the middle of a section of code (ie, inside an if statement or loop) which would cause major problems with what the code expects.
Trying to enforce  'you can't do that' to prevent such things is way beyond the capabilities of HuC as it stands.
Not saying it -can't- be done, just placing it up there with structs: it would be nice, but not with the current state of the code


So, which of those fixes do you think would be easiest to do? And, aside from arrays (we all know that sux), which would be most important?

You know, he isn't called "TheOldMan" because hes young.

Too true. And I walked 5 miles uphill, barefoot in the snow to school.
Both ways

[OldRover]

A proper compiler knows that you can't goto a label outside of a function. It's the job of the compiler to ensure that labels outside of the proc are never jmp'd to. But anyway, it doesn't really matter... it's a minor thing. I wouldn't really miss it if it wasn't implemented. Of course, everything can be made a mess in the wrong hands...

As far as the most important bits... I would say bank optimization (top issue), library modularization (second most important issue), and 24 bit variables for addressing purposes. Whether or not any of these are easy is another story.

[Arkhan Asylum]

A proper compiler knows that you can't goto a label outside of a function. It's the job of the compiler to ensure that labels outside of the proc are never jmp'd to. But anyway, it doesn't really matter... it's a minor thing. I wouldn't really miss it if it wasn't implemented. Of course, everything can be made a mess in the wrong hands...

Right, but all of that checking/security/enforcement has to be put in place in the compiler lol... it sounds easy on paper until you start to implement it and realize all of the overhead...which is why doing it manually with assembly is less work.  Just stick it in where you need it.  You don't have to generalize it's use if you are manually doing it for your specific case that arose where you need a goto. 

[Keranu]

I have not understood a single word from this thread.

[Arkhan Asylum]

I have not understood a single word from this thread.

Blazing Lazers.

Happy?

[Keranu]

PERFECT, thank you!

[OldMan]

A proper compiler knows that you can't goto a label outside of a function

Are we still talking Huc here? BTW, I just checked in gcc, and I get one complaint, about the label not being defined. So yeah, I guess jumping to labels in other routines would be the compilers problem. But it would still involve adding code to recognize when you have a label, modifying the symbol table layout, etc. Doable, but not easy until the code gets cleaned up

As far as the most important bits... I would say bank optimization (top issue), library modularization (second most important issue), and 24 bit variables for addressing purposes.

I would swap the first two around: modularize the libraries first, then work on bank optimization.
Why? Because the libraries would need changed to use/respect the .proc/.endproc markers, otherwise they will still end up in one huge bank. My biggest problem there is that is definately going to break existing code - not that I care that much. The old version would still be available.

And, fwiw, it's a lot harder than it seems to modularize the libraries. Several of the routines are just wrapper calls that map things in, execute the code, and then restore the original mapping. Which wouldn't be too bad if the assembler code didn't flip-flop banks seemingly at random. I'm still tracking down exactly what code runs in what bank

I may look into bank optimization, though. I suspect it would require more than either of us think. To do it right, you would have to generate the code in a temp area, find the page it would fit 'best' in, and then go back and patch all the addresses... At least, that's what I -think- it would take.

[OldRover]

I may look into bank optimization, though. I suspect it would require more than either of us think. To do it right, you would have to generate the code in a temp area, find the page it would fit 'best' in, and then go back and patch all the addresses... At least, that's what I -think- it would take.

I would probably do something along those lines... generate each proc and account for the sizes, then starting from the largest, find smaller procs that would be the best fit for its bank. It's not easy, but hey, I'm not afraid of hard work.

[Arkhan Asylum]

And, fwiw, it's a lot harder than it seems to modularize the libraries. Several of the routines are just wrapper calls that map things in, execute the code, and then restore the original mapping. Which wouldn't be too bad if the assembler code didn't flip-flop banks seemingly at random. I'm still tracking down exactly what code runs in what bank

Yes, very annoying.  The flip flopping is irritating.



Keeping track of labels properly for goto'ing doesn't seem like it would really be worth the amount of time it would take to get it in and working properly.   

Rover, or Touko, do you have any C GOTO examples that would really sway my opinion here?

[OldRover]

Not really. It's just a matter of code generation. The output from a goto is going to be less than other methods, and every byte counts here. And furthermore, if someone were to try to goto a label outside of the function, fuck 'em... they're a stupid coder anyway.

[touko]

Rover, or Touko, do you have any C GOTO examples that would really sway my opinion here?

Yes, a simply exemple, checking pad entries .
In C you must cascading if else, elseif .
Many generating code to do that, in ASM a single jmp do the same.

another one, when your entry was tested, a simple pointer jmp avoids to recheck all entries, untill previous action was finished.

And a code with GOTO and good comments, is better than a lack pure C one IMO .

In a real C application, if GOTO is bad, globals variables are bad too .

[spenoza]

Actually, I've heard a lot of good arguments that global variables are indeed bad...

[OldRover]

Global variables... depends on the application. I've yet to actually hear any real arguments against them outside of "compiler confusion" and "name collision". The first can be fixed by forcing compiler makers to get off their lazy asses and fix their shit, and the second can be fixed by forcing coders to get off their lazy asses and fix their shit. You obviously don't always use globals, because in normal coding, local variables are often more efficient, and the larger the application, the more noticeable it becomes. However, in HuC, it's the other way around... globals are noticeably better for a multitude of reasons, not the least of which being the fact that HuC has *still more bugs* when it comes to variables... I discovered this when fully entrenched in MSR's code. It's hard to explain and even harder to trace, but it worked like this...

In two cases, global variables declared at the module level were not acting as designed. This was noticeable when doing cutscenes. The values of two variables were being ignored by if statements and were incrementing to their full values before overflowing and coming back to levels where if would recognize their value range. This was especially apparent in the case where I was using one to do a palette rotation... the colors spazzed out for quite awhile before they finally started cycling correctly. However, this problem only manifested when the game had been running for awhile... if you just started up the game and used the debugger to go directly to the parts where the bug happened, they worked as designed. So I figure it was memory corruption of some kind. However, by moving these variables out of the module and into globals.h, the problem disappeared entirely and things worked as designed all the time.

[OldMan]

Don't confuse HuC with a 'real' C compiler.....

In a real c compiler, if could do something like

jv = joy(0);
mask = 0x01;
for( i = 0; i < 8; i ++ )
{
    if( jv & mask )
   {
        *(f)();
        return;
   }
   mask <<= 1;
}
and have a seperate routine for each joystick button. Compact, and on a real compiler, pretty efficient.

If you need gotos to do joystick handling, you might want to re-think your code. Either use a case statement, or subroutines for the inner part of the ifs. Long, nested ifs themseleves aren't bad: but too much code between the if and the else can make it hard to follow.

And yeah, global variables are another one of those good/bad situations. No one wants to type in 50 parameters to a function call, so they have their uses, even in 'real' C. But they definately make things harder to follow and debug.
...........................................................................

Unfortunately, no better options exist in HuC. Live with it. Let's just decide what -can- be fixed

[The opinions expressed here are those of the author. You have the right to your own opinion. Don't flame me for what I think unless you have a really good reason for another viewpoint. Personally, I have been programming for 20+ years, and only used a goto -twice-. Of course, I'm not trying to write the most optimized code, either. I am with Ritchie (of K&R): Make it work first. Then, go measure it so you know what needs speeded up. Then, and -only- then, go back and make it fast ]

[OldRover]

I've noticed that switch generates a ton of overhead. It seems like it's actually better to use a series of if comparisons rather than a switch. This can present major problems when writing state machines or control schemes.

[OldMan]

I've noticed that switch generates a ton of overhead. It seems like it's actually better to use a series of if comparisons rather than a switch.

In Huc, probably (lol). In 'real' C, not so much. At least I don't think so because I've never measured it.

I would have to check how many if/elseif/else statements it would take to match the overhead of a switch in HuC.
But, at some point, a switch -is- going to be 'better'.

And if you're writing state machines in HuC using if's, it's not going to be very efficient. At least, not until the pointer problems get fixed.

[OldRover]

At present, I'm writing state machines with switch but it consumes buttloads of code space. I've had to split complex FSMs across two functions because of the huge amount of code waste it generates.

[OldMan]

[Personal opinion below. Not commenting about your code. Just my approach to the problem]

I've had to split complex FSMs across two functions

Only two?? The point of a FSM is using the 'state' as an index to a function call. I could -never- keep that much code straight in my head! Somewhere here I have an 8 state machine that handles double-jumping and acceleration for sprite movement, and it's probably 14-15 subroutines. I can't imagine trying to do that in just 2!

[OldRover]

I've never had to use more than 3 functions to do a complete entity system. Monolith uses this three-function setup for the player entity. Most of the state handler is interlaced with the controller scheme, which uses two functions. The third function handles all the states that are not affected by the controller scheme. Other entities require a single function for their state machines. Valkyrie Midnight uses a two-function system with independent controller scheme and state handler, but that's fine because the system is way less complex. Monolith uses almost twice the number of states so I made it as efficient as possible. Right now, I'm also working on a Bomberman-type game, and the state machines only have 5 states... two functions only, and they will both fit in the same code bank. If I wanted to be even more efficient, I could put the entire thing into one function... but I think that that's overkill, and would require a redesign anyway. No sense in breaking something that already works great.

[MotherGunner]

Good read even though I don't understand it much, thanks guys.  Btw seeing both of you old men go back and forth on this thread reminded me of Trading Places!  Ha ha ha!

But who is Randolph and who is Mortimer? 

[OldRover]

Dunno... I'm probably Mortimer.

[Arkhan Asylum]

switches are faster than if's if you set them up right.  I did experiments with that in both C and C#, lol.  It's not a huge speedup, but it's a speedup. 

go figure its the opposite in HuC.

globals are great, as long as you aren't passing the code around for others to work on also.   For a game project or something of this caliber, globals are fine.  You'll have 1 to 3 people actually using them, and if you can't keep it straight between the 3 of you, you're all retarded.

lol


Pointers to functions would be great.  then we could do some real programming.

[OldMan]

Pointers to functions would be great.  then we could do some real programming.

Working pointers (to functions or not) would be good. <lol>

I think I'll dump the HuC library files to a printer and start modularizing that, first.
Then, maybe, optimizing code packing.

Oh, and I'm the one who's the flunky. The guy standing up, iirc.

[OldRover]

Pointers to functions would be great.  then we could do some real programming.

set_joy_callback() is the only place I've seen it so far. I use it in MSR during cutscenes so they can be skipped.

[touko]

With huc switch/case are very slow, i don't use that statement in huc ..
i have tested with if, elseif, and it's more efficient in term of speed, but code is very dirty too .

You can test, with a single proc call in a vsync ..
test your proc with if, elseif, and with switch case ..

Another strange thing with Huc ..

spr_set(1) (not the only one), huc convert this function in asm with :

Code Select Expand

ldx #low(1)
lda #high(1)

call _spr_set
Just fine   ..

just with this liltle routine you can loose up to 128 cycles/frame .

[Arkhan Asylum]

With huc switch/case are very slow, i don't use that statement in huc ..
i have tested with if, elseif, and it's more efficient in term of speed, but code is very dirty too .

You can test, with a single proc call in a vsync ..
test your proc with if, elseif, and with switch case ..

Another strange thing with Huc ..

spr_set(1) (not the only one), huc convert this function in asm with :

Code Select Expand

ldx #low(1)
lda #high(1)

call _spr_set
Just fine  ..

just with this liltle routine you can loose up to 128 cycles/frame .

I didn't mean testing it on HuC, because I don't expect HuC to do anything the traditional (read: correct) way.

If it's fast/useful in C, it's probably jacked up in HuC.

Structs are missing, pointers are broke, arrays are derped, and iirc, >> and << don't perform better than / and *.

so, yeah, it's barely even C.  Let's start calling it HuB

[touko]

Yes arkhan switch/case are those cool stuffs on C that sucks in HuC ..

I think that HuC needs to be refund entirely,actualy it is functional, no more no less.
I also think it will be more a waste of time to change, rather than start from scratch IMO.

But who'll have the skills here to do this ?
Ultimately, one person could handle the compiler, and others may do functions, libraries , startup etc ...

A good HuC version, needs to be less noobinators (copyright Arkhan) to be optimal, and keep version 3.21 for beginners.

[Arkhan Asylum]

I also think it will be more a waste of time to change, rather than start from scratch IMO.

Not really.  The problems in HuC could be tweaked and fixed.  Starting from scratch would be nice, but would be way more work. 

But who'll have the skills here to do this ?
Ultimately, one person could handle the compiler, and others may do functions, libraries , startup etc ...

TheOldMan and myself might be the only two compiler-capable people here.  I'm no expert like OldMan, but I can do some things. ;).  The problem then becomes, is it worth the time for us to sink into doing this as opposed to making games. 

A good HuC version, needs to be less noobinators (copyright Aetherbyte) to be optimal, and keep version 3.21 for beginners.

fixed.

[spenoza]

If fixing HuC would lower the bar of entry and make it easier for others to get into the scene and start pumping out fun games, then I would say it would be better to fix HuC to ensure a more diverse range of homebrew offerings.

[Arkhan Asylum]

it would lower the bar but still require you to know how to program and work with limited resources.  That sort of talent is falling by the wayside more and more every day.

[grahf]

True, but at least it would give people a chance to see something on the screen more easily and whet their appetites.

[Arkhan Asylum]

True, but at least it would give people a chance to see something on the screen more easily and whet their appetites.

In HuC's current state, it's still easy to get things on the screen.  The problems arise when you get deeper into the mechanics of a game.  About the only thing HuC does good is put sprites on screen and move them around.

New people won't notice the differences really until they get reallllllllly into it.

[OldRover]

Indeed. When you're deep into a project like MSR with multiple overlays, dozens of variables at several scopes, and stack abuse that would make K&R either cry or bow in worship, you will see just how broken the system really is and why it needed to be maintained. HuC is perfectly usable as-is and works great for making Hucard games. When you get into making CDs, things can get unpredictable.

[Arkhan Asylum]

It really only works great for HuCard games.  The CD stuff is definitely where things start to get derpolicious.

[spenoza]

So HuC would be perfectly adequate for an arcadey shooter or platformer, but it's apparently craptastic for RPGs?

[Arkhan Asylum]

So HuC would be perfectly adequate for an arcadey shooter or platformer, but it's apparently craptastic for RPGs?

Platformer, yeah.

Arcadey shooter, maybe.  Depends how apeshit you go with the graphics. 

[OldRover]

It's hard as hell to make an RPG to begin with, let alone one with HuC and all its flaws. As for arcade shooters... well, that depends on a lot of things... if you have a lot of enemies/bullets/etc, using arrays to keep track of it is going to give your game more slowdown than 95% of SNES games. Using individual variables is great for speed but is going to bloat the fuck outta your code. If only arrays didn't suck...

[mrhaboobi]

anyone considered dropping dave shadoff a line to see if he updated hu c at all?  i see he has an active site ( active in that it still exists un like zeograd which appears to be dead.  Rover for some of us newbs explain to us where you learnt the basic of gaming?  by trade i write tcp/udp based mobile applications, but not much experience in gaming algorithms etc.. have basic stuff up and running on yaroze ( psx dev ) and xbox, but its really some of the underlying principles on game dev and algorithms and how to deal with gravity when doing platformers etc that im keen to understand.  old schoool game coding i guess

[Arkhan Asylum]

Dave Shadoff?

Who do you think said "It's not worth fixing if no one is using it."

lol.  I ran all of the problems with HuC by them on IRC and was met with apathy: The recurring PCE Dev theme.

I think the entire original "TGHack" crew is about done with doing anything.  They had their glory days back in 1996-2005ish, and now have moved onto other things.  They still float around/post (kind of)/chat on IRC...but they aren't doing anything.  They didn't seem too interested in doing anything either. Maybe one day they will again.

The one guy is a phantom (Jens).  He just disappeared.  I asked where he went and was given a "don't ask" response, implying there is a grudge or some lingering loldrama.  *shrug*.  He would have been great to prod for info when Squirrel was a new idea.  Oh well.

I myself learned the basics of game programming from a few books for Windows (One for 2D, one for 3D, one for DirectX and one for RPG design), screwing with allegro (tons of open source crap!), messing with RPG Makers (Verge, RPGMaker2000399024), screwing with QBASIC games, and doing crap on the C64 (type-ins, experimenting...).

Those goony old books for 8 bit computers really do a good job of explaining things about games that you don't get told anymore.  Crazy.

[touko]

eh, I also forgot a more faster cd_loadvram() 

[Arkhan Asylum]

lol..

The thing I want most is structs.

[touko]

If squirrel will become a part of huc, i want the sound of jarre's laser harp  in it  

[Arkhan Asylum]

lolol

[OldMan]

Now that I have an idea of what would need fixed, What would be the best way to distribute modifications?

[Arkhan Asylum]

A downloadable .zip/.rar from Aetherbyte's site?