A New version of Huc

[touko]

http://pcedev.blockos.org/viewtopic.php?f=5&t=99&sid=4271ff003c2cb9398848a023e55028dd

 

I don't know, who did it ..

Edit: i found it ,it's Ulrich Hecht ..

[Arkhan Asylum]

Good thing this arrived after Atlantean is basically done, lol.

ugh.

but, fuck yes nonetheless.

[OldRover]

Is there an actual download for it?

EDIT: nvm, it has a download option on the righthand side.

[Arkhan Asylum]

lol I am curious how compatible it is with stuff that was written with current HuC.

I'm betting if I send Atlantean through it, we will get a giant mess.

[spenoza]

Good thing you're so close to being done you don't need this for Atlantean. Still, you've got your source. Could be an exercise in experimentation. What will the new HuC do to this thing I know works?

[ParanoiaDragon]

lol I am curious how compatible it is with stuff that was written with current HuC.

I'm betting if I send Atlantean through it, we will get a giant mess.

Then you could release that has an Extra-Special Edition!

[Arkhan Asylum]

That's kind of what I intend to do once Atlantean is actually done. 

Atlantean will be the final proof that you can complete a HuCard PCE game with HuC, despite everyone saying it's a giant shitheap. 

lol.

and then I'll run the code through NuC, and be like oh wow.  This would've saved me about a year.

[OldRover]

Hrm, source only, and I have not yet tried to build it in gcc/mingw... will try later today though.

[OldMan]

Let us know how it goes.  I trashed my cygwin install, and haven't tried yet under (an old version of) MingW.
I'm interested to see what optimizations it has made to the pce code.

[Arkhan Asylum]

I'm going to start banging away at it after I finish Atlantean.   I'd love to use it FOR Atlantean, but since it's literally like, done, it'd be more trouble than it's worth lol.

Maybe we can feed the pre-optimized Insanity through it, and see if it runs like shit still!

yeahhhh!

[OldRover]

Code Select Expand

main.c: In function 'dumpglbs':
main.c:606:3: error: implicit declaration of function 'fmemopen' [-Werror=implic
it-function-declaration]
   data = fmemopen(data_buf, DATABUFSIZE, "w");
   ^
main.c:606:8: error: assignment makes pointer from integer without a cast [-Werr
or]
   data = fmemopen(data_buf, DATABUFSIZE, "w");
        ^
main.c:608:10: error: assignment makes pointer from integer without a cast [-Wer
ror]
   rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
          ^
cc1.exe: all warnings being treated as errors
make[4]: *** [main.o] Error 1
make[4]: Leaving directory `/c/huc-master/src/huc'
make[3]: *** [huc] Error 2
make[3]: Leaving directory `/c/huc-master/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/huc-master/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/c/huc-master'
make: *** [all] Error 2

[OldRover]

The included docs say that it does not work with mingw. That's silly.

[OldRover]

Doesn't build through cygwin either.

Code Select Expand

dave@elsiedell ~/huc-master
$ make
make[1]: Entering directory `/c/cygwin64/home/dave/huc-master'

 -----> make all in src
/usr/bin/make --directory=src all
make[2]: Entering directory `/c/cygwin64/home/dave/huc-master/src'
make[3]: Entering directory `/c/cygwin64/home/dave/huc-master/src'

 -----> make all in huc
/usr/bin/make --directory=huc all
make[4]: Entering directory `/c/cygwin64/home/dave/huc-master/src/huc'
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c code.c -o code.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c const.c -o const.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c data.c -o data.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c error.c -o error.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c expr.c -o expr.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c function.c -o function.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c gen.c -o gen.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c io.c -o io.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c lex.c -o lex.o
cc  -Werror -Wall -g -O2 -Wno-char-subscripts -c main.c -o main.o
main.c: In function 'dumpglbs':
main.c:606:3: error: implicit declaration of function 'fmemopen' [-Werror=implic                                                                                                                it-function-declaration]
   data = fmemopen(data_buf, DATABUFSIZE, "w");
   ^
main.c:606:8: error: assignment makes pointer from integer without a cast [-Werr                                                                                                                or]
   data = fmemopen(data_buf, DATABUFSIZE, "w");
        ^
main.c:608:10: error: assignment makes pointer from integer without a cast [-Wer                                                                                                                ror]
   rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
          ^
cc1.exe: all warnings being treated as errors
make[4]: *** [main.o] Error 1
make[4]: Leaving directory `/c/cygwin64/home/dave/huc-master/src/huc'
make[3]: *** [huc] Error 2
make[3]: Leaving directory `/c/cygwin64/home/dave/huc-master/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/cygwin64/home/dave/huc-master/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/c/cygwin64/home/dave/huc-master'
make: *** [all] Error 2

[OldMan]

I saw the MingW blurb, which is one reason I havent' snagged it yet. I do vaguely remember cygwin and mingw going seperate ways after Win7, so that may be the reason.

Wonder if he forgot an include file (with the def of fmemopen() ), or if fmemopen() isn't available in that version of cygwin ??? I've had similar things happen with strndup(), so you may need a specific version of cygwin to build it... <sigh>

...or we could just turn off 'warnings as errors' and see what happens

[OldRover]

From /usr/include/stdio.h:

Code Select Expand

/*
 * Routines in POSIX 1003.1:200x.
 */

#ifndef __STRICT_ANSI__
# ifndef _REENT_ONLY
#  ifndef dprintf
int _EXFUN(dprintf, (int, const char *__restrict, ...)
               _ATTRIBUTE ((__format__ (__printf__, 2, 3))));
#  endif
FILE * _EXFUN(fmemopen, (void *__restrict, size_t, const char *__restrict));
/* getdelim - see __getdelim for now */
/* getline - see __getline for now */
FILE * _EXFUN(open_memstream, (char **, size_t *));
#if __BSD_VISIBLE || __POSIX_VISIBLE >= 200809
int _EXFUN(renameat, (int, const char *, int, const char *));
#endif
int _EXFUN(vdprintf, (int, const char *__restrict, __VALIST)
               _ATTRIBUTE ((__format__ (__printf__, 2, 0))));
# endif
#endif
so it's not like it's not there. I think the makefile might be misconfigured.

[OldMan]

Hmmm... The error you get (implicit declaration of function 'fmemopen') actually means the compiler hasn't seen a declaration for fmemopen yet.....

Downloading now. Will see about building it tomorrow.

[OldRover]

Yeah I know, it's odd. The source specifically includes stdio.h so I don't know why it isn't seeing it, unless there is a #define issue somewhere. I scoured the source for potential issues but found none.

[Arkhan Asylum]

just use #define _GNU_SOURCE...

[OldMan]

Ok rover. Here's what I got so far:

Using XP, SP3. Installed latest cygwin (V 1.7.29, 32 bit). Unzipped the files (all my tg16 stuff is in a directory off the desktop called TG16). Ran cygwin batch file, got into cygwin shell. went to huc-master directory and tried compiling. Ooops. Can't find command "cc". Fixed src\make_src.inc to define CC   <CC=gcc>
Compiled, and at least main got built. No complaints about missing fmemopen().

Maybe you're using an old version of cygwin/gcc ?
I do remember reading last night that mingw is missing fmemopen(). Don't know if they fixed that problem or not, so it's another possibility.
Shall we keep setup instructions here, or make a new thread when we figure it out ?

[OldMan]

Update: After moving things around and getting HuC to run (I never install things in the default locations, and am only passingly familiar with where what goes in *nix systems), I compiled an older
joystick test program. And it runs, so the compiler itself isn't broken.

Next up is to see if I can get sprite demo working...and Arkhan: I didn't change anything (not even function definitions) in the test program, so Atlantean -should- just compile and work....
Unless the assembler screws up

FYI: HuC still ids itself as v 3.21, Denki. That really needs fixed....
pceas is 3.23, nop release.

[Arkhan Asylum]

Well, it's mostly a matter of "Does Ulrich's sound driver he wrote jive well with what Squirrel barfs out?", for Atlantean.   If the chip tunes aren't rockin' it isn't going to work! lol.

He had asked about redistributing Squirrel.  I told him sure as long as he didn't change anything.   Through some miscommunicating sort of/retard moments from me, I realize he could've just jammed it all in. (He had it running)

However, he said in the end, he's glad he didn't have to work with it since it was jammed in HuC a bit haphazardly, since it's HuC, and basically everything is pretty haphazard.  His new thing is cleaner. 


Here's to hoping the New HuC (NuC!) is awesome and we get to bang away at it and do nice things.


We should probably look into what it would take to get Squirrel's player crammed in there, for future use from us, and others.   We can probably get it hooked in cleaner if we poke at it enough.

and then Atlantean can really be the last thing we ever do with 3.21 HuC, since it hurts.

and everyone can rejoice at all the things ever.

[esteban]

Tell me about Ulrich...I know nothing about him (did he have a hand in the initial releases of HuC, for example? Or did he come along later and take on the Hydra that is HuC?)

Thank you. 

[cabbage]

Just got cygwin, and, after getting everything set up correctly with the required packages, had working binaries. I tried compiling a few demos which were laying around, and there was a noticeable increase in speed. With the new features and optimizations, this is a much appreciated release!

edit: squirrel seems to be working too 

[OldMan]

Just got cygwin, and.....

Can you post which version of cygwin and which packages you installed? So others can follow along.

edit: squirrel seems to be working too

?? More information please...

[Arkhan Asylum]

edit: squirrel seems to be working too 

Oh good, the one other developer that uses Squirrel can tell us what is up.

I'm going to try building it right now to run Atlantean through it to see if my chiptunes play.  It'd be good if there's a fresh card player library that isn't at the mercy of the old HuC's gooniness to actually work right.



As for Ulrich, I don't think he was a part of the original HuC.    If he was, it wouldn't have been such a mess in the first place probably, lol.

[OldMan]

edit: squirrel seems to be working too

Confirmed. I ran my squirrel test program through the new HuC, and it plays the sound. I'm not an audio nut, so as long as it makes noise, that's good....
But when I tried building our slideshow iso, chiptunes fail miserably. It tries, but ends up looping and looping. No graphics show up, and only the start of the tunes play.  Looks like it won't work for cds

....Arkhan reports errors with some #defines. Those appear to be in a header file, and a simple #ifndef / #endif should fix that problem.
More annoying is that you can no longer offset from a palette identifier in load_pal().  Apparently
'load_palette(1, titPal+(32*4), 1);' will no longer work to access different palettes included from a single file....

(16 entries per palette * 2 bytes per entry == 32 bytes. Multiply that by 4, to get the start of the fourth palette. That's what he's doing - and only loading that one palette.
The error is 'can't get farptr', which means the offset is probably computed correctly, but the pointer is assumed to be in the address space, making it a near pointer - which it shouldn't be. Probably a bug in the load_palette macro, since it worked before. )

All in all, I'm pretty pleased so far. I haven't tested it extensively, but if this is all the errors, it will be nice to see how much it speeds things up

[cabbage]

uname -a ----> CYGWIN_NT-6.2 blah 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin
(i just used the automatic installer from the cygwin site)

I wasn't sure what packages would be needed so I grabbed: gcc-core, gcc-g++, gcc-objc, gcc-objc++, libgcc, and make. (also from the auto downloader/installer)

There could be conflicts with other toolchains, so be aware of that. I needed to remove from my PATH variable because of SGDK's own make.exe, but other setups could have different conflicts (or none at all)

At this point it was working and could compile the HuC source. There was an error (about zlib.h or something) on the tgemu portion of the build, but the important stuff seems fine.

Then when I tried using huc from outside of the cygwin environment (ie, in a normal windows cmd prompt) I got an error about cygwin1.dll. Added the path to cygwin's bin directory to my PATH environment variable, which solved that.

[Arkhan Asylum]

Yeah, I just fresh installed Cygwin, added all the GCC stuff + Make, and it built with zero issues.

Atlantean won't build because I need to bitchslap the sound-stuff that it includes... but I bet it'd build otherwise.

[cabbage]

After playing around with it some more, I am beginning to think there are a lot of changes and the transition to this new version could be rockier than I had hoped. I've tried rebuilding some old projects, and they're successfully compiling, but the games are fucked. E.g. Sprite data seems to load OK, but BG is just garbage.  I've also run into the same farptr error TheOldMan mentioned...

Re: squirrel, CD projects definitely seem to be having more trouble than Hu ones.

I figured I would try starting a little project from the ground up, and couldn't even get it playing nicely with a mappy tilemap. I tried the exact same code on the old HuC and it worked as expected.

So... definitely more research is needed

[Arkhan Asylum]

Yeah that Farptr error is from when I tried building Atrantean.   lol.

[OldMan]

but BG is just garbage.
....
couldn't even get it playing nicely with a mappy tilemap

Problem confirmed. I don't get 'garbage', but we have a few tools to do things to backgrounds, so it may be because of that.
Looking with the mednafen debugger, I can confirm the tile data gets loaded to VRAM correctly (at least at the right address), and is visible for display. However, it shows up as a black background, possibly because it uses palette 0.
I haven't checked a lot, but it appears to me that the BAT is either being loaded incorrectly, or not being loaded at all.

I am beginning to think there are a lot of changes and the transition to this new version could be rockier than I had hoped.

Agreed. I'm beginning to wonder if it is/will be useful at all
Shall we continue checking / debugging, or just drop it ?

(Cabbage: I can send you my test, which is about as minimal as you can get for displaying a sprite and background, if you would like. It's an example from a how-to I made for someone here a long time ago. )

[OldMan]

Update:
Oh, this made me chuckle for a while.

In the source code for the new HuC:
psuedo.c call amatch() to check for psuedo-operations (ie, #defines)
amatch calls astreq(). astrreq() compares characters, exiting if it hits a null, presumably.
.......
All of which is well and good, until you compare "tile" to "tile_ex".
"tile" will end in a null. So "tile" and "tile_ex" will match.
Unfortunately, the if/else if chain is set up to compare "tile" before it checks for "tile_ex"...
so it appears the code to match tile_ex will never be executed.

Now this was just a quick look to see what was going on, and I may be wrong...I'm not familiar with all the details of how those functions actually work, but it still looks fishy to me.

[megatron-uk]

Oh, FFS. The Everdrive-FAT libraries would be much further on if I'd had this to play with to start. 

[TurboXray]

Just a FYI - PCEAS build of this package based on my 3.22 Tomaitheous release.

 Copy/paste from Mooz's forum:

Ahh ok, I see. It is. But, there's a possible incompatibility with old PCEAS generated code here; local label names used in high lever expressions. I added the ability to do .- and .+ (.+, .++, .---, .----, etc) for local labels. And you can use this just fine in expressions.. *IF* you use a space. The release that came with 3.21 Denki allowed you to do .local+$33. But you can no longer do this in this new version. You have to use spaces in between the operator symbols and label names, else it thinks ".local+" is the label. So, .local + $33 works fine, in the new build. But not without spaces, if that makes sense.

 I probably should have added a switch with compatibility mode for this part of PCEAS. I might do so, since I need to add a couple of things to PCEAS (macro function stuffs).

[MintyTheCat]

Hi,

I managed to build under Ubuntu:

Linux 'NAME' 3.2.0-64-generic-pae #97-Ubuntu SMP Wed Jun 4 22:22:15 UTC 2014 i686 i686 i386 GNU/Linux

However, I had to turn off the 'warnings promoted to errors' as:

CFLAGS = -Wall -g -O2

In file: huc/src/Make_src.inc

A bit naughty, but the author was not checking his return and trying to be strict  O:)

The Sample/designer builds successfully for me.

Hope that helps one of you as I had not seen anyone report trying to build under Linux as yet.

Cheers,

Minty.

[OldRover]

It makes me chuckle to think that someone decided to go all-out Linux for something that is primarily used by Windows users. Not only that, but HuC has been cross-platform for as long as I can remember... the same source has always built with no modifications on any x86 OS with gcc, afaicr.

[MintyTheCat]

It makes me chuckle to think that someone decided to go all-out Linux for something that is primarily used by Windows users. Not only that, but HuC has been cross-platform for as long as I can remember... the same source has always built with no modifications on any x86 OS with gcc, afaicr.

Glad to add some humour ;)

I tend to work as often as I can under some kind of Unix.

That I would say is the beauty of the Command-Line - I wrote all my Megadrive tools to be Command-Line tools that use nothing special in the hope that they will build every where and build well into the future.

[Arjak]

Bump.

I am considering trying to get into PCE programming, so I looked at this new version of HuC, but there is no compiled binary available, and I couldn't find clear instructions on how to compile the compiler.

It drives me crazy when programmers just give you some source code and expect you to figure it out, especially those arrogant types who basically act like you don't deserve to use the program if you can't compile it yourself. It's like they feel that they've done their part by writing the code, and so they don't have to make that last step of creating binaries for easy use, basically saying it's the user's problem. Lazy bums!

What should I do? Should I just go with the older version? Can someone get me a compiled version of this? Or is there a better tool that I should use that I don't know about?

[Arkhan Asylum]

You could get away with using the "current" HuC instead for now really.   

I mean basically, if you can't compile the new one, the features it has probably won't matter to you for now really.


As you can see from our games, the current one is more than enough to get somewhere.

Figure out how to deal with the new HuC after you get your feets wet.

[Lochlan]

I am considering trying to get into PCE programming, so I looked at this new version of HuC, but there is no compiled binary available, and I couldn't find clear instructions on how to compile the compiler.

There's a makefile build system, just type `make` in your console (in your *nix shell, of course!).  However after building I couldn't get any of my projects to compile so I don't really consider that version of HuC to be particularly reliable.

It drives me crazy when programmers just give you some source code and expect you to figure it out

Wellllll it is a github repo, i.e. source code, so I think the expectation there is pretty reasonable.  He could tag releases but it's his project and he gets to run it however he wants.  And IMO it is extremely bad practice to commit built files to a repository (although not uncommon, unfortunately) as you should be able to produce the built files by running the build system on source.  Committing built files can create a lot of annoying issues with merging and rebasing.

It's like they feel that they've done their part by writing the code, and so they don't have to make that last step of creating binaries for easy use, basically saying it's the user's problem. Lazy bums!

You know what's even worse than that?  End-users who complain that they don't get enough with their free software.

What should I do? Should I just go with the older version? Can someone get me a compiled version of this? Or is there a better tool that I should use that I don't know about?

http://www.zeograd.com/huc_download.php

[Arjak]

You know what's even worse than that?  End-users who complain that they don't get enough with their free software.

Heh, fair enough. I did get a little obnoxious there, as I tend to do when I rant about something that's frustrating me. I often forget to look at things from the other side. I apologize if I offended you or anyone else, Lochlan.

I do not use Unix or Linux, so I have no way of compiling the new version apparently. My current computer runs Windows 7, since that's what I'm comfortable with, for better or worse. At least my problem is solved for the moment. I've downloaded the latest "official" version, and I'll start working on Rover's tutorials at Obeybrew.com when I get the chance.

Speaking of Obeybrew.com, what's the status with that? It seems really...broken. 90% of the links lead to an error page. Is Rover still working on it? Any ideas of when it will be updated?

[cabbage]

I do not use Unix or Linux, so I have no way of compiling the new version apparently. My current computer runs Windows 7, since that's what I'm comfortable with, for better or worse.

you can compile it on windows using cygwin
but you might as well just stick with the old version for the time being.

Speaking of Obeybrew.com, what's the status with that? It seems really...broken. 90% of the links lead to an error page. Is Rover still working on it? Any ideas of when it will be updated?

i think rover has bigger things on his plate for the time being.

just focus on the basics at first. loading tiles, sprites, palettes, and displaying them properly; reading inputs and moving sprites around, etc.
the real meat of game programming is fairly platform-independent (collision detection, for example), so you can still find plenty of applicable tutorials and whatnot to help you out.

and, of course, i imagine there are several people (myself included) who would be happy to help you out if you run into something confusing and need some tips.

start small--have you tried making something like pong for pce yet? i know there are plenty of pong homebrews out there already, but it could be a good learning experience