lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Apr 29, 2022 9:55:58 GMT
elmerWill HuC still receive feature updates in the long run or is KickC the new place to be to stay up to date with PCE C programming? I don't think I have seen any thread comparing both solutions yet. Could you give some hint points performance wise or is it more a syntax conveniency( ANSI 99 comp. )? Is it compatible with existing sound engines or will it be an opportunity to bring new tools on stage?
|
|
|
Post by elmer on Apr 29, 2022 15:28:10 GMT
Will HuC still receive feature updates in the long run or is KickC the new place to be to stay up to date with PCE C programming? I won't personally be doing any feature updates to HuC in the future, but will do bug-fixes if they're needed, and turboxray may take over and choose to continue making updates. I have been merging his changes into my HuC branch so that I can keep up-to-date with his improvements, whenever he makes them public. However, both of us feel somewhat constrained by the desire to keep HuC compatible with its 20-year-old HuC/MagicKit libraries, which do not (currently) allow for modular improvements. I have been working on producing a set of modular and improved libraries (and examples) that can be used by both KickC and assembler programmers, kinda like a modern version of the old MagicKit, but which takes advantage of the 20+ years of advances in knowledge about the PC Engine, and of newer programming techniques in general. KickC is really not C99 compatible, but it follows the same HuC philosophy of breaking standard-C compatibility where that makes sense for performance on a 6502 CPU. It also generates *much* better code than HuC, because it's built around modern compiler technology that just wasn't available when HuC was created. For those that value standards-compliance over speed, I am aware of the work being done on the LLVM-MOS compiler, but that is not my current target. Moving new assembly-language libraries (such as turboxray's deflemask player) to the KickC/ASM environment that I have set up shouldn't be difficult, but that is up to turboxray ... and he's been too busy with real-life to really take a deep dive into my work to see if it matches the direction that he wants to go in for a newer "TurboGrafx Development Kit". Moving over mixed assembly-language and HuC libraries (such as 0x8bitdev's sprite and background libraries) will require a bit more work, because KickC is definitely not compatible with HuC, but my KickC conversion of HuC's example "shmup.c" project, which can be found in github, shows that there *can* be good compatibility (and better-but-not-best performance) with most C code. At the end of the day, my KickC/ASM envrionment is really just an expanded version of the current HuC environment, allowing for more RAM for C variables (only on CD or on a SuperGrafx), and wasting less memory with fixed banks and a monolithic library. Really, for most developers who just want to get on with writing games in C, HuC is currently the reasonable choice, and KickC is only a bleeding-edge option for people that are also comfortable with assembly-language, and who are willing to work around things that don't exist yet. The more libraries and support code that are written to be compatible with KickC, the more viable an option it becomes for C developers. We're just not there, yet.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Apr 29, 2022 16:28:49 GMT
Alright, thank you for the update elmer o/ I'll stick at HuC for the time being then.
|
|
|
Post by spenoza on May 16, 2022 18:38:24 GMT
I know this refrain is like a broken record, but a basic, unencumbered, default music engine is still an outstanding need for HuC (and for any potential replacement like KickC). There are clearly programmers capable of rolling their own, but having a basic starting point throws open the doors to more accessible development, which has the potential to bring more people, including artists and musicians, to the platform. I think there's also a need to have a standardized "stable" branch of HuC or KickC for PCE. I know folks are working (or were working) on their own directions, but it would be nice to have agreement all around on a core branch to merge to that's considered stable and establishes a compatibility point with a solid enough development flow that adding features later doesn't threaten to break old code (within reason).
I think it's awesome that folks are working on new ideas, including a variety of possible audio engines, but right now people are clearly still confused as to where to start with HuC. Which version, where do I get it, etc... I see a lot of great discussion from folks dipping in their toes, but it feels like we're still not quite where we need to be.
The expertise for these steps clearly exists here on this forum, but available time and energy seems to be a serious limiting factor (and as a working parent I get that). Some of us (like me) don't have the skills to contribute to the technology side. Is there anything we can do to facilitate or enable those of you who do? Maybe a maintained "where/how to get started with HuC" thread with the top posts being the links to various resources with guidance provided by the community? A separate web site somewhere else that does this? I don't mind checking in with folks periodically to make sure content is updated and correct.
Not only that, but what other things, if any, does HuC to become more noob friendly?
|
|
|
Post by dshadoff on May 16, 2022 19:11:19 GMT
Some of these things are being worked on. Specifically, while elmer and turboxray both have slightly different branches of HuC: - turboxray has been wrestling to get a sound engine ready (I feel that he should speak about its relative state of readiness though) - elmer has continued to fix bugs in HuC - both have synchronized parts of their trees in the past several months, so while there are still differences, they are smaller than before - both agree that there should be one unified version, but there is still some work needed in order to get there. They are working toward this. Additionally, I am working with another person on a better version of Mednafen, which will include bug fixes, missing functionality, and new debug functionality. This isn't available in release form yet, but if you are able to build your own Mednafen, it can be found here: github.com/pceDev16/mednafenPceDevOne more thing... as we are building these things, in order to make them "an authoritative source", we are planning to create a GitHub "organization", and move these repositories to that organization's account. That way, we will unify the codebases as well as allow more than one person to make changes (and each of us can avoid being the bottleneck), and allow pull requests from the community, to democratize the process a bit. Ultimately, we'd like to put as many (relevant) tools and information sources as possible into repositories of this organization's account. I can't give a specific schedule for this (I am hoping it's all in place by end of summer), but I hope this gives some idea of what's going on behind the scenes to make things easier for PC Engine developers.
|
|
|
Post by elmer on May 17, 2022 17:20:02 GMT
Not only that, but what other things, if any, does HuC to become more noob friendly? From my POV, just for a start, better documentation, and better examples. This has been mentioned multiple times, and it is not something that really requires one of the huc-maintainers to do ... any experienced user could help with it, if they wished to be helpful. A quick for-instance ... there are 4 files in huc/doc that document the existing library ... 1) "clibref.htm" in English, dated 2000-08-17, which says that it has 60 functions documented. 2) "clibref_fr.htm" in French, dated 2001-08-15, which says that it has 118 functions documented. 3) "clibref_fr.txt" in French, dated 2001-08-15, which looks like it also has 118 functions documented. 4) "clibref.txt" in English, dated 2005-04-09, which looks like it has a few more than the 118 functions documented. Wouldn't it be nice if all of the documents were up-to-date and actually matched each other?
|
|
|
Post by gredler on May 17, 2022 19:17:04 GMT
I totally agree that we can and should document what we know and work collaboratively towards spreading as much concrete information as possible. The amount of tribal knowledge paired with the multiple out of date sources for publicly available knowledge must make entrance to this effort super frustrating if not a blocker for a lot of people. I think the first step for us has to be establishing a open wiki available for edit and some moderators who keep backups and restore information if trolls intentionally bork it up ( spenoza I think this would be where you can be a huge help). Before I start researching wiki options, I know others have tried but I really hope we can get those posted here and we can all jump on one to get a central publicly curated info repository. As for content I think the first steps is adding the combined and consolidated versions of all existing documentation, editable by anyone, with moderators put into place who can confirm a wiki entry is approved/confirmed and version checkpoint that entry. Would this be something that sunteam_paul would want to integrate adjacent to this forum and the bible page itself? I would love to help out with this in any way I can.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on May 17, 2022 20:28:27 GMT
When I started 3 months ago, I took the habit to use this wiki as a helper for my devs. It's already a lot of information gathered here. Maybe we could focus on this one and update it? Adding an example section? www.archaicpixels.com/Main_PageIs it possible to add all prototype functions in "huc.h" with some formatting in order to use helpers from modern editors like Visual Code? for example (from SGDK) : /** * \brief * Returns RGB color value from CRAM for the specified palette entry. * * \param index * Color index (0-63). * \return RGB intensity for the specified color index. */ u16 PAL_getColor(u16 index); Although I don't have any idea how to make #inc pseudo code not being detected as typing error.
|
|
|
Post by gredler on May 17, 2022 20:45:13 GMT
Yeah elmer's tools thread, archaicpixels, and obeybrew tuts ( obeybrew.com/index.html) are the go to spots for me, but to Elmer's point the included documentation and these other locations could fairly easily be combined into a central location. Also, as far as I know Rover is not updating obeybrew anymore because he's busy knee deep in development projects and archaicpixels is also abandonded. If we can add stuff to archaicpixels that would be my vote and I would definitely be down to contribute. I wonder why Rover's obeybrew tuts aren't on there. I agree that adding some example project stuff on there would be very helpful. For instance I have a little test rom setup for loading art and checking it on hardware/emulator that has no game logic but is handy for me to confirm I didn't break art before handing it off to a programmer, but that would probably be very useful for a beginner looking to make pixel art show up on their everdrive or emulator
|
|
|
Post by DarkKobold on May 17, 2022 21:06:32 GMT
Not only that, but what other things, if any, does HuC to become more noob friendly? Having worked with GBDK, SGDK, HuC, PVSneslib, monogame, and some libGBA, I feel qualified to answer this question. HuC is incredibly noob friendly. It's far less complex than SGDK. It doesn't require banking like GBDK. PVSneslib is absurdly complex, and libGBA has the worst tutorial of all time. obeybrew.com/tutorials.html - Anyone with basic coding skills can get through this and be programming games. archaicpixels.com/Main_Page - Everything you need as far as function calls. We have two major problems: No public sound engine any composer wants to use. For Catastrophy, we went through a boatload of composers that said a flat "No" to MML. So, it's a waiting game for turboxray's HuTrack. I've used it, and it's incredible. It's just not available to everyone yet. No singular github repository. There's at least 5 copies of HuC floating around. Some active, some dead. So, new people come in, and have no idea which repository to use. I don't know how, but there's a single github for GBDK, and all the main coders just agree to use that one.
|
|
|
Post by elmer on May 17, 2022 21:31:04 GMT
but to Elmer's point the included documentation and these other locations could fairly easily be combined into a central location. Well, if someone actually brought the included text files up-to-date, that's at-least 50% of the work in creating a new wiki. Everything else is formatting. The project *should* ship with documentation, relying 100% on a webpage is (IMHO) crazy. Now, the html files in the documentation ... they should probably just be nuked since they were created in Mircosoft Word, and nobody is going to want to keep those darned things up-to-date.
|
|
|
Post by elmer on May 17, 2022 21:57:13 GMT
No singular github repository. There's at least 5 copies of HuC floating around. Some active, some dead. So, new people come in, and have no idea which repository to use. I don't know how, but there's a single github for GBDK, and all the main coders just agree to use that one. Well, as dshadoff said previously, there's work afoot to try to consolidate things so that there's a central location to start looking. Apart from that ... people get to choose who's version they want to use, including the original v3.21 if they want to. You do remember, don't you, that until very recently, there was nobody but me doing any updates to HuC, or fixing things that were broken, and Uli's excellent work was mostly being ignored because there were some crash bugs that he never fixed. Now that there are other developers willing to make changes and move the toolchain forward, we're at the point where we'd all benefit from some co-ordination ... and so that's happening. Sure, just as long as nobody *EVER* comes up with something new ... like say a HuC map and sprite library that is a bit more advanced than the primitive 20-year-old stuff that's currently in HuC. Sure, they can be programming games that don't include sound (when turboxray releases his library), and they'll be programming with the (IMHO) frankly-awful graphics tools that are built into HuC.
|
|
|
Post by DarkKobold on May 17, 2022 23:05:10 GMT
Sure, just as long as nobody *EVER* comes up with something new ... like say a HuC map and sprite library that is a bit more advanced than the primitive 20-year-old stuff that's currently in HuC. Sure, they can be programming games that don't include sound (when turboxray releases his library), and they'll be programming with the (IMHO) frankly-awful graphics tools that are built into HuC. This is in response to the "noob" question. Is it absolutely everything you could possibly ever use? No. Is it everything you need (that actually exists publicly) to get started? Yes. I already pointed out the lack of a sound engine. Its not like a wiki can cover an unreleased sound engine, or that would be helpful to a noob at all. Also, the "multiple options" is not good when it comes to something like a compiler which we want new people to use. Right now, there's the incredibly dated GBDK, which hasn't been supported in years, and GBDK2020, which is actively being developed and supported. Even with this, you still run into new coders that accidentally use the old version and get frustrated.
|
|
|
Post by gredler on May 17, 2022 23:05:27 GMT
but to Elmer's point the included documentation and these other locations could fairly easily be combined into a central location. Well, if someone actually brought the included text files up-to-date, that's at-least 50% of the work in creating a new wiki. Everything else is formatting. The project *should* ship with documentation, relying 100% on a webpage is (IMHO) crazy. Now, the html files in the documentation ... they should probably just be nuked since they were created in Mircosoft Word, and nobody is going to want to keep those darned things up-to-date. Completely agree. I would hope the included documentation would only be text files, and are up to date and combined. Having the web accessible repository webpage to me is a separate resource that imo should have the documentation matching what's included but also examples and images etc.
|
|
|
Post by gredler on May 17, 2022 23:38:10 GMT
I know this refrain is like a broken record, but a basic, unencumbered, default music engine is still an outstanding need for HuC To give some hope about the progress of turboxray's deflemask based sound engine for huc, here is a recording of me testing it on the express using the usb2ted and a test rom I made for checking out music and sfx,
|
|