What Needs Fixed In Huc?

[Arkhan]

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

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

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]

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]

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.

[nodtveidt]

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]

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]

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. 

[nodtveidt]

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

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

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