PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum

Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: TheOldMan on October 05, 2011, 05:45:24 AM

Title: What Needs Fixed In Huc?
Post by: TheOldMan on October 05, 2011, 05:45:24 AM
Moved discussion from 'MSR is finished" to here.
................
Quote

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.

Quote
-"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..

Quote
-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. :)

Quote
-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)

Quote
-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.

Quote
-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.

Quote
-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....

Quote
-C++ style comments (would help with verbose output, I think)
Have that.

Quote
-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.

Quote
-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.)

Quote
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.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 05, 2011, 06:38:24 AM
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... :)

Quote
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! :D   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.  :)

Quote
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

Quote
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.

Quote
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...

Quote
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.

Quote
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". 
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 05, 2011, 06:51:33 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 05, 2011, 07:25:11 AM
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.



Quote
from the 70s.
You know, he isn't called "TheOldMan" because hes young.

lol.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 05, 2011, 07:39:45 AM
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". f*ck "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.
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 05, 2011, 07:50:59 AM
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....

Quote
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?


Quote
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 :)
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 05, 2011, 08:02:20 AM
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. :)
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 05, 2011, 08:11:37 AM
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. 

:)

Title: Re: What Needs Fixed In Huc?
Post by: Keranu on October 05, 2011, 12:25:56 PM
I have not understood a single word from this thread.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 05, 2011, 12:31:35 PM
I have not understood a single word from this thread.

Blazing Lazers.

Happy? :)
Title: Re: What Needs Fixed In Huc?
Post by: Keranu on October 05, 2011, 12:59:19 PM
PERFECT, thank you!
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 05, 2011, 03:30:59 PM
Quote
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 :(


Quote
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.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 05, 2011, 03:45:49 PM
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. :D
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 05, 2011, 05:22:33 PM
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?
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 05, 2011, 06:38:35 PM
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, f*ck 'em... they're a stupid coder anyway.
Title: Re: What Needs Fixed In Huc?
Post by: touko on October 05, 2011, 08:38:11 PM

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 .
Title: Re: What Needs Fixed In Huc?
Post by: spenoza on October 06, 2011, 06:36:36 PM
Actually, I've heard a lot of good arguments that global variables are indeed bad...
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 02:36:03 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 07, 2011, 02:38:44 AM
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 :) ]
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 02:51:03 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 07, 2011, 03:05:25 AM
Quote
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.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 03:33:10 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 07, 2011, 03:51:07 AM
[Personal opinion below. Not commenting about your code. Just my approach to the problem]

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

Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 04:10:40 AM
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. :D
Title: Re: What Needs Fixed In Huc?
Post by: MotherGunner on October 07, 2011, 06:13:05 AM
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?  :twisted:

(http://images.starpulse.com/Photos/Previews/Trading-Places-p10.jpg)
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 06:17:27 AM
Dunno... I'm probably Mortimer. :D
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 07, 2011, 07:25:21 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 07, 2011, 07:33:15 AM
Quote
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.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 07, 2011, 08:01:25 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: touko on October 07, 2011, 08:47:50 AM
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]
ldx #low(1)
lda #high(1)

call _spr_set
Just fine  :-" ..

just with this liltle routine you can loose up to 128 cycles/frame .
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 09, 2011, 04:11:16 PM
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]
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
Title: Re: What Needs Fixed In Huc?
Post by: touko on October 09, 2011, 08:34:50 PM
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.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 10, 2011, 01:15:51 AM
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. 

Quote
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. 


Quote
A good HuC version, needs to be less noobinators (copyright Aetherbyte) to be optimal, and keep version 3.21 for beginners.
fixed. :)
Title: Re: What Needs Fixed In Huc?
Post by: spenoza on October 10, 2011, 09:24:54 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 10, 2011, 10:17:33 AM
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.

Title: Re: What Needs Fixed In Huc?
Post by: grahf on October 11, 2011, 02:30:27 AM
True, but at least it would give people a chance to see something on the screen more easily and whet their appetites.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 11, 2011, 02:33:07 AM
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.

Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 11, 2011, 06:14:23 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 11, 2011, 07:47:21 AM
It really only works great for HuCard games.  The CD stuff is definitely where things start to get derpolicious.
Title: Re: What Needs Fixed In Huc?
Post by: spenoza on October 11, 2011, 04:40:09 PM
So HuC would be perfectly adequate for an arcadey shooter or platformer, but it's apparently craptastic for RPGs?
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 11, 2011, 04:44:41 PM
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. 
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 11, 2011, 05:18:34 PM
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 f*ck outta your code. If only arrays didn't suck...
Title: Re: What Needs Fixed In Huc?
Post by: mrhaboobi on October 11, 2011, 10:17:52 PM
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 :)
 
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 12, 2011, 01:29:42 AM
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.
Title: Re: What Needs Fixed In Huc?
Post by: touko on October 14, 2011, 03:05:18 AM
eh, I also forgot a more faster cd_loadvram()  :D
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 14, 2011, 04:07:09 AM
lol..

The thing I want most is structs.
Title: Re: What Needs Fixed In Huc?
Post by: touko on October 14, 2011, 05:52:13 AM
If squirrel will become a part of huc, i want the sound of jarre's laser harp  in it  [-(
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 15, 2011, 07:43:22 AM
lolol
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 17, 2011, 04:21:58 AM
Now that I have an idea of what would need fixed, What would be the best way to distribute modifications?
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 04:45:23 AM
A downloadable .zip/.rar from Aetherbyte's site?
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 06:03:05 AM
I have obeybrew.com... erm... brewing... it could be hosted there too.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 06:09:28 AM
lol, I demand credit for the term obeybrew.

Is it going to be that one-stop-shop PCEDev information hub we talked about like 5 months ago?
Title: Re: What Needs Fixed In Huc?
Post by: TheOldMan on October 17, 2011, 06:11:33 AM
It's not the actual hosting I'm wondering about...Like arkhan says, we could do that at aetherbyte.

But what's the best form for distributing changes? Do we really want to put up a new zip everytime anyone changes things? Or would a base zip and diff files work better? How would we manage it when multiple people make changes?

An svn, for devs only? Any other ideas?
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 06:20:11 AM
Yeah Ark, that's the plan. :) And you get due credit for the name. :P

Oldman, that's not a problem really. HuC isn't very big. A single maintainer works as long as they're not a slacker. :) I don't think it's a good idea to make it all stupified like a lot of projects are. The way it is right now is simple and effective... just download, unzip, and use. Screw messing around with svn. :) Besides, I doubt too many people are gonna wanna mess with HuC directly anyway... more people are interested in using it than working on it.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 06:29:46 AM
I vote against SVN for something of the magnitude of HuC.  It ain't big enough. If it is hosted at Aetherbyte, Oldman or Myself are more than able to ftp the latest and greatest build for everyone, while keeping track of the old builds as well.

how does this sound:

a page at Aetherbyte (aetherbyte.com/HuC.php) that has a link for the download of the latest and greatest stuff...

and the rest of the page will be a changelog so you can always see whats been done.

and, obeybrew.com can just link to that page so everything is coming from a central location.


I doubt many people will be modifying HuC's source aside from OldMan, Myself and Rover... so having a dev-only access to the source for screwing with seems like more trouble than it is worth.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 07:09:58 AM
That sounds good to me. It might be wise to mirror it though, just in case. But you guys are doing most of the work, so it's up to you.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 07:16:04 AM
Mirroring could work.  I don't know how crucial that would be once the 4 people who want HuC get the latest build... lol
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 07:26:34 AM
It's not terribly crucial, but meh... you never know how things might go.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 07:28:42 AM
yeah.

the changes will probably not be rapid enough to warrant diff/svn .     I see this happening slowly and steadily.  basically, "Denki" will be put to rest, and a new version name and number will be made.  Take it or leave it.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 07:33:36 AM
HuC 4.0 Sushi. :lol:
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 08:01:51 AM
screw that HuC 4.0 YourMom.  lol
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 08:37:08 AM
HuC 4.0 OnlyRoverWillUseThis :P
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 08:41:50 AM
HuC 4.0 OnlyRoverWillUseThisAndAetherbyte,Obviously :P

lol.

I hope more people will.. but even with a great C compiler, the learning curve for the turbob is kind of steep.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 08:54:20 AM
Yeah, it's kind of steep. I think it'll be easier for newcomers though... stepping down from the nearly unlimited "modern" C/C++ on the advanced systems of today can be a nightmare for people who have to adapt to the terribly limited system of the PC Engine. On the other hand... things like sprites are way easier here than on the PC since everything is handled by the hardware and you don't have to worry about blitting pixels like you do in a framebuffer environment.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 08:55:38 AM
but, blitting is the least of your worries really.  lol.

thats trivial business.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 09:00:22 AM
True, but that was actually the biggest hurdle for me after being so used to direct access to the entire pixel array. Then again, experience with the Commodore 64 and its similar video hardware helped a ton. I feel sorry for anyone who has only ever used software blitting... and even worse for scrubs who've only ever used Direct3D. I was already very schooled in C by the time I got to coding the PC Engine, so adapting to the slightly different paradigm wasn't all that hard. Working without structs and having to use the old-style function prototypes wasn't that big a deal in the long run. C++ scrubs are gonna have a hard time though... no inheritance = "OH NOES WAT DO I DO NOW WAAH" :lol:
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 09:08:11 AM
I like blitting but only for certain things.  There are times where I would kill for blitting on the PCE.
Title: Re: What Needs Fixed In Huc?
Post by: mrhaboobi on October 17, 2011, 09:25:00 AM
sounds like there is deffinately some scope for you old timers to write some how to docs and make life for us newbs a bit easier ;)
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 10:13:29 AM
I plan on writing docs.  I have been for awhile.  I liked writing the doc for Squirrel, and tried to keep it clear and simple.

I wouldn't mind writing more documents like that.  I think I am pretty good at it, but I may be wrong.
Title: Re: What Needs Fixed In Huc?
Post by: nodtveidt on October 17, 2011, 10:55:46 AM
Documentation has always been the real Achilles heel of PCE homebrew. Even the docs for HuC, which are some of the best ever done for PCE homebrew, are lacking and contain errors, not to mention entire functions left completely out (such as cd_fade(), which was such a critical function for MSR's presentation).
Title: Re: What Needs Fixed In Huc?
Post by: spenoza on October 17, 2011, 11:26:03 AM
I started with Apple Basic, did a little Pascal in high school, and Java in college, and I never did enough of any of them to do squat short of data organization. I would be less worried about graphics and program structure and tracking variables than I would enemy behavior. For me AI, even the most simple routines, is quite scary.
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on October 17, 2011, 01:07:32 PM
Documentation has always been the real Achilles heel of PCE homebrew. Even the docs for HuC, which are some of the best ever done for PCE homebrew, are lacking and contain errors, not to mention entire functions left completely out (such as cd_fade(), which was such a critical function for MSR's presentation).

Yeah I like how some parts of the doc say "Im too lazy to do this", or something, lol.


Not to toot my own horny horn, but Squirrel is probably the best document related to PCE.  lol.

some of the other hardware related ones are nice too, but not entirely helpful to someone trying to do basic C programming (AKA: Get a sprite to move on the screen)
Title: Re: What Needs Fixed In Huc?
Post by: BigusSchmuck on November 27, 2011, 05:43:55 PM
Ok gentlemen, where can I get the latest version of HuC and not the old one on Zeograd's Lair?
Also, is there Arcade Card support on this program or are we just limited system card 3.0 stuff?
Title: Re: What Needs Fixed In Huc?
Post by: Arkhan on November 28, 2011, 12:27:12 AM
Ok gentlemen, where can I get the latest version of HuC and not the old one on Zeograd's Lair?
Also, is there Arcade Card support on this program or are we just limited system card 3.0 stuff?


Just stick to the Zeograd one (3.21) for now.

The fixes won't matter to you until you get balls deep into a project.

:D