gator
Deep Blooper
Posts: 24
|
Post by gator on May 1, 2022 1:28:15 GMT
Hi, PC-Engine enthusiast here Sorry if I missed the info, but I'm trying to understand what version of Huc to use (and let's be crazy, maybe contribute to) as there are several forks of Huc that don't have the same changes (elmer, dshadoff, turboxray). Is there any plan to consolidate the various dev efforts into a single repo ? Maybe under a github 'organization' rather than an individual accounts ? Sorry in advance if this was already previously answered
|
|
|
Post by elmer on May 1, 2022 3:07:27 GMT
Sorry if I missed the info, but I'm trying to understand what version of Huc to use (and let's be crazy, maybe contribute to) as there are several forks of Huc that don't have the same changes (elmer, dshadoff, turboxray). Hahaha ... good question, especially if you're willing to build from the source in github! dshadoff has said for a while that he'd update his fork with my latest changes ... but he hasn't, yet. His fork contains no actual new changes, just pre-built (and out-of-date) linux and windows executables. I merged all of turboxray's public changes into my fork a few months ago, and then spent time fixing a few things that were broken in his fork. turboxray has said for a while that he'd update his fork with my latest changes when he's ready ... but he hasn't, yet. For many years I was the only developer making changes, but since dshadoff and turboxray created their forks, we've never really discussed getting HuC's presence on github organized, and they've never submitted a pull-request for their changes, although we do often talk about other things. At this point, it's up to you who's repo you wish to fork off!
|
|
|
Post by dshadoff on May 1, 2022 15:17:13 GMT
My "huc" repository is a fork from elmer's from late 2020, making it roughly "v3.99"... my only changes were to fix a few compile errors which had crept in due to gcc updates (and to build binaries). I did not intend to add new features or support HuC; I only wanted a version that I could run on linux.
Since then, elmer has put in... looks like about 160 commits, so some pretty substantial work.
Turboxray - if he is to merge in elmer's fixes - will need to re-fork directly from elmer's source; currently turboxray is forking off of monstersgoboom's form of elmer's.... but monstersgoboom has archived their fork... I expect that this severs the communication from elmer's version to turboxray's version.
|
|
|
Post by elmer on May 1, 2022 17:04:58 GMT
Turboxray - if he is to merge in elmer's fixes - will need to re-fork directly from elmer's source; currently turboxray is forking off of monstersgoboom's form of elmer's.... but monstersgoboom has archived their fork... I expect that this severs the communication from elmer's version to turboxray's version. I merged from turboxray's fork using the command-line git, so the basic git tech seemed to be able to deal with the different fork path ... but I don't think that you can do it (easily) from within the github interface.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 1, 2022 17:57:37 GMT
Thanks for your answers. I'm more of a CI/CD person, so the lack of automated build pipeline/tagging/testing caught my eye And indeed, I hit the issues dshadoff fixed when having fun dockerizing the toolchain, but I was using turboxray fork back then. I think the community would benefit from having a centralized version handled by the 3 of you, using the full potential of github (or let's be crazy gitlab) and leveraging Issue Tracking / Merge Requests / ... But, given how KickC is growing, maybe it would be more productive to contribute to adding all the bells and whistles needed for PCEDev to KickC.
|
|
|
Post by elmer on May 1, 2022 18:18:05 GMT
I'm more of a CI/CD person, so the lack of automated build pipeline/tagging/testing caught my eye I think that we'd *love* to have CI/CD set up for HuC, and for the PC-FX toolchain, if someone with the skills would do it! And indeed, I hit the issues dshadoff fixed when having fun dockerizing the toolchain, but I was using turboxray fork back then. Yep, the linux build does occaisionally get broken, because I don't build it as often as I build my Windows working-environment, but it is *supposed* to always work. I think the community would benefit from having a centralized version handled by the 3 of you, using the full potential of github (or let's be crazy gitlab) and leveraging Issue Tracking / Merge Requests / ... We're already collaborating on another part ot the PCE enviroment, so creating some kind of centralized organization definitely has merit. But, given how KickC is growing, maybe it would be more productive to contribute to adding all the bells and whistles needed for PCEDev to KickC. That's my feeling, too ... which is why PCEAS can now build KickC-generated code, and why KickC itself now supports the HuC6280 CPU. At this point, we mostly need more library work to be completed before KickC is a usable environment to PCE C programmers.
|
|
|
Post by turboxray on May 1, 2022 20:57:24 GMT
turboxray has said for a while that he'd update his fork with my latest changes when he's ready ... but he hasn't, yet. Well, my fork isn't really public and it's WIP. Also, your changes to PCEAS broken my game - so I didn't have time to figure out why haha. Still busy
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 1, 2022 21:56:26 GMT
I'm more of a CI/CD person, so the lack of automated build pipeline/tagging/testing caught my eye I think that we'd *love* to have CI/CD set up for HuC, and for the PC-FX toolchain, if someone with the skills would do it! I'd be glad to help on that topic if we can agree on an official source of truth repo to use
Speaking of PCEAS, will it still be needed in the future ? As far as I understand, KickC generates an .asm file, and can then use the actual Kick assembler to generate the final output (-a option IIRC) (and maybe need a couple of config files in /targets/ directory to properly generate a usable PCE executable ?)
As for the work on libraries, is it just about adding a couple of #ifdef in the c code to make it compile on HuC and KickC ?
|
|
|
Post by elmer on May 1, 2022 22:11:54 GMT
Well, my fork isn't really public and it's WIP. Also, your changes to PCEAS broken my game - so I didn't have time to figure out why haha. Still busy Hahaha ... touché! Take your time, and I'm happy to help figure out what got broken in your setup ... but I do need information if I'm going to help.
|
|
|
Post by elmer on May 1, 2022 22:57:59 GMT
Speaking of PCEAS, will it still be needed in the future ? As far as I understand, KickC generates an .asm file, and can then use the actual Kick assembler to generate the final output (-a option IIRC) You can generate functional PCE code with a KickC/KickAsm combination, but you're going to be somewhat limited in the amount of code that you can use, and where it is. If you're very, very careful about how and when you manually switch banks, then you can even generate large amounts of code ... you'll just need to manually move it around to fit into the banks. PCEAS handles all of this stuff automatically, using the same mechanism that it uses for HuC (with a few minor tweaks). It's also the "familiar" PCE environment for people that want/need to drop into assembly-language for any tasks. KickAsm is not compatible with existing PCE ASM libraries, and does not handle PCE banking with anywhere near the simplicity/elegance of PCEAS. OTOH, KickAsm is *very* powerful in certain areas, far more so than PCEAS, but those are areas that I've never used in over 40 years of ASM programming, and they're not used by any of the code that KickC generates either, so I'm not sure who they're targeted to (maybe the C64 folks that KickAsm seems to have been written for?). So "yes", from my personal POV, PCEAS isn't going anywhere, and Jesper (KickC's author) has shown an interest in keeping KickC compatible with PCEAS in the future, now that I've done the work to make PCEAS understand the KickAsm code that KickC generates, and to actually improve on KickAsm by supporting the automatic long-branch fixup that KickC needs. As for the work on libraries, is it just about adding a couple of #ifdef in the c code to make it compile on HuC and KickC ? HuC libraries that want to get any kind of reasonable performance are actually written in ASM and not in C ... so nope from the POV of sharing libraries with a #ifdef. Most ASM libraries could be sharable and usable in both environments, but it requires the author to want to support both compilers. Making C games that work with both compilers ... why on earth would you want to? Just pick one. The switch to KickC is a chance to get rid of some old HuC libraries that just don't hold up to modern standards.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 2, 2022 0:36:02 GMT
Thanks for the lengthy explanation, it's very appreciated. I've witnessed games made with 2 compilers, but it was a long time ago (PS3 era), mostly during a transition phase, as it's a huge waste of resources to keep the whole build chains alive. On the middleware side, it's another story, and we had to support all flavors (similar to the ASM libraries you mentioned) If the combo KickC / KickAsm is indeed the future of PC Dev, then support will be needed from the various lib authors. One thing a bit scary though is the warning at the end of the readme.md in kickc repo, mentioning it's beta, and can basically blow up in your face Let's hope the author moves to 1.0 someday, and follows semantic versioning, to offer a robust dev environment.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 9, 2022 21:22:42 GMT
Ok, I had some fun getting familiar with the GitHub way of doing CI/CD (or Actions), and I'm experimenting with a fork. I flipped a 3 sided coin and forked the Elmer repo. github.com/kikmon/huc/actions/runs/2296558224What I have so far: - Ubuntu build - Msys2 build - Docker container generation (to have a convenient way of running the toolchain) - Static Code analysis github.com/kikmon/huc/security/code-scanning?query=is%3Aopen+branch%3Acitest- Security check on the docker container (not perfect yet) Msys2 build is failing because of an ifdef controlling the separator character for PCE_INCLUDE variable (; vs : ) (and maybe other errors later) Not sure what's the official process for building on Windows Is this the right place to discuss these topics?
|
|
|
Post by elmer on May 11, 2022 17:30:10 GMT
Cool stuff! Msys2 build is failing because of an ifdef controlling the separator character for PCE_INCLUDE variable (; vs : ) (and maybe other errors later) Not sure what's the official process for building on Windows Errr, Msys2 is what I'm using, and have no build issues here. Then again, I checked-in some changes only 3 days ago to fix multi-cpu builds and clean up some stuff so that HuC could build on a Mac. Is this the right place to discuss these topics? It's probably as good a place as anywhere else for the time being!
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 12, 2022 0:55:54 GMT
Ok, I refreshed my fork with your latest changes and msys2 is still failing. I get the same behavior locally and on the build machine, so maybe there's something in your setup I'm not aware of. As far as I understand, the source of the issue is that WIN32 isn't defined when compiling. so at /src/mkit/as/input.c (83), the code defines the include path separator as : and not ; But in the makefile, the 'windows' platform is properly detected, and the makefile sets PCE_INCLUDE with ; separators. The result is the paths aren't tokenized properly, and pceas fails to include pceas.inc So I'm curious to understand why it 'works on your machine' and not in a fresh environment. Any clue ? Is your setup able to magically find the includes in the non WIN32 default locations ? "/usr/local/lib/huc/include/pce;" \ "/usr/local/huc/include/pce;" \ "/usr/local/share/huc/include/pce;" \ "/usr/local/include/pce;" \ "/usr/lib/huc/include/pce;" \ "/usr/share/huc/include/pce;" \ "/usr/include/pce"
I didn't know mac support was also a thing. I might as well add it to the CI
|
|
|
Post by elmer on May 12, 2022 2:14:33 GMT
I get the same behavior locally and on the build machine, so maybe there's something in your setup I'm not aware of. As far as I understand, the source of the issue is that WIN32 isn't defined when compiling. so at /src/mkit/as/input.c (83), the code defines the include path separator as : and not ; Or perhaps there's something in your setup that I'm not aware of! For a start, if the GCC compiler isn't automatically setting WIN32 ... then you're not actually running Msys2's mingw-w64 GCC compiler. "gcc -dM -E - </dev/null | grep WIN32" should display the 4 variations of WIN32 that gcc defines by default when running on a Windows machine. If you're running in Microsoft's "Windows Subsystem for Linux" ... I can't help you, that's not Msys2! A simple ... cd /usr/local git clone https://github.com/jbrandwood/huc.git cd huc make
... works fine for me on a Win64 machine. Now, you do need to run msys2_shell.cmd with the "-mingw64" parameter in order for it to set up the compiler, else gawd knows where your GCC installation is coming from.
Depending upon how you installed Msys2, that may or may not be the default for your setup.
FWIW, HuC also builds fine on a Linux machine, and even a Mac now apparently, just as long as GNU Make is your default, and not Mac OS's (BSD?) Make.
Anyway ... how on earth are you getting a "/usr/local/lib/huc/*" directory? HuC builds entirely in-tree into "huc/bin/" If y'all are trying to run "make install" after the build ... good luck! You'll need to talk to dshadoff about systemwide installation on linux, I only build HuC in my linux user directory. Anyway, even if "make install" works, it doesn't set up a PCE_INCLUDE path, or put anything in "/usr/local/lib/huc".
|
|