DutchDimension
Punkic Cyborg
Posts: 122
Homebrew skills: Pixel, 2D and 3D art
Fave PCE Shooter: Override
Fave PCE Platformer: Mizbak's Adventure
Fave PCE Game Overall: Too many to choose from
Fave PCE RPG: Ys series
|
Post by DutchDimension on Sept 28, 2021 2:35:30 GMT
@dutch As for the self-destructive comment. I mean it's not like it takes a whole community to put out a product. Pretty much just need one person to code, and someone for music/graphics. If you're converting graphic assets, even easier to find someone. A project like this is very doable, even with SGX support. It just takes motivation and dedication. Ohh, and time. Not sure about other devs, but something I never seem to have enough of hahah. That's fair enough. I just hope that one day we'll actually see some genuine new HuCard titles. But I know what you mean about lack of spare time. There's always something getting in the way of PC-E time it seems. Anyway, your work looks great. The tools you've been developing generate some really good results. I hope someday they will be publicly available and proof their worth in the best trial of all, production of an actual game. Great stuff. Please post more eye-candy if you can!
|
|
|
Post by turboxray on Sept 28, 2021 18:15:37 GMT
@dutch As for the self-destructive comment. I mean it's not like it takes a whole community to put out a product. Pretty much just need one person to code, and someone for music/graphics. If you're converting graphic assets, even easier to find someone. A project like this is very doable, even with SGX support. It just takes motivation and dedication. Ohh, and time. Not sure about other devs, but something I never seem to have enough of hahah. That's fair enough. I just hope that one day we'll actually see some genuine new HuCard titles. But I know what you mean about lack of spare time. There's always something getting in the way of PC-E time it seems. Anyway, your work looks great. The tools you've been developing generate some really good results. I hope someday they will be publicly available and proof their worth in the best trial of all, production of an actual game. Great stuff. Please post more eye-candy if you can! I'm just trying to show it's not all doom and gloom haha. Thankfully, no one is gate keeping information. Documents and knowledge has been out there for decades.. just scattered around a bit. People dependent on C, might find it a bit frustrating though(I'd like to know Nicole's experience since she kinda jump into HuC recently), but asm side of things is pretty straight forward as it gets. Stuff is still happening.. it's just now regulated to discord and private channels. Finished products are desired, but I also like 'what if' demos and scenarios. Pics, small game demos, etc. It's actually a popular concept in the MD and NES dev areas.
I actually have a pretty decent working version of a deflemask player for PCE (and not a 'vgm' player) - I've posted some WIP roms of it running on twitter. DK has helped me test it in HuC too (very grateful for that help!) - with samples and everything. We got sound FX to work along side music tracks. Unfortunately, HuC was in need of some interfacing logic updates - so the music engine needs that build of HuC. I just don't have the time to retro-fit things to older versions of HuC. I also have an exciting map engine library. I plan to release that too, for HuC. The plan is to release all this stuff to the public, including whatever tools and source code. It's just that I don't have a lot of free time, so things tend to move slowly. Other people are working on exciting stuff too, but since they haven't made that public.. I won't mention it yet haha. If I can make stuff that helps people dev new things on the PCE, then I'm pretty happy.
|
|
|
Post by spenoza on Sept 28, 2021 18:58:48 GMT
Wasn't Elmer also working on a Deflemask engine? He's been pretty silent of late. It would be pretty cool to see an engine ready to just drop into a project and feed music files.
|
|
|
Post by elmer on Sept 28, 2021 20:32:00 GMT
Wasn't Elmer also working on a Deflemask engine? He's been pretty silent of late. It would be pretty cool to see an engine ready to just drop into a project and feed music files. Yes I was (am???). I've been having some extended time-off to recharge my interest in coding stuff. Back in 2018, Michirin9801 and I were waiting for Delek to fix some things in Deflemask, but then he went dark for a couple of years while he was working on other stuff. It looks like he has finally started releasing updated versions of Deflemask again, and that he may have fixed at-least some of the problems that Michirin9801 was having, so maybe I'll take another look. OTOH, Michirin9801 got discouraged by all the negative feedback from the boys-club around here (at that time), and without her, I don't see anyone else that is really pushing high-quality game-ready PCE chiptunes forward. Anyway, apart from that, I have really lost interest in working around the limitations of HuC development any more, because it just got too frustrating. I think that turboxray has already taken over as the person to talk to about new updates in that area, especially since he has already done his own work on a Deflemask player (and other exciting new stuff).
|
|
|
Post by dshadoff on Sept 28, 2021 22:56:33 GMT
I guess it's time to start talking about assembler development then. (and any other tools etc.)
|
|
|
Post by elmer on Sept 29, 2021 1:16:49 GMT
I guess it's time to start talking about assembler development then. (and any other tools etc.) I do believe that there's still a bright future for further HuC development, and that HuC itself is an absolutely amazing way for folks to get started in game development on an old platform like the PCE ... but yeah, IIRC you and the other creators of HuC envisioned it as a path for folks to started, and that new developers would then transition into assembly language development once they needed to do more than HuC provided. Something like Unity shows that there is a legitimate need for an easy way for new developers to get into game development, while hiding the "difficult" parts of gamedev inside professionally-written libraries and systems that the new developers just treat as "magical" black-boxes. HuC provides a similar kind of system the PCE, but its capabilities can only grow if HuC's library and fundamental organization are allowed to change from the way that it was originally written. Both Uli, and then me, had ideas about how that could be accomplished, and if there are HuC developers that are open to change, then Turboxray will be able to (has already?) make his own changes that he feels improve HuC for developers. As for assembly development moving forwards ... that's a good question. There are still some overlay and startup-related changes to ISOlink and PCEAS that are specifically targeted at assembly language development that I would like to check in somewhere ... but they break my last build of HuC.
|
|
|
Post by dshadoff on Sept 29, 2021 2:47:30 GMT
but yeah, IIRC you and the other creators of HuC envisioned it as a path for folks to started, and that new developers would then transition into assembly language development once they needed to do more than HuC provided. That's true, that's what we had been thinking at the time. As for assembly development moving forwards ... that's a good question. There are still some overlay and startup-related changes to ISOlink and PCEAS that are specifically targeted at assembly language development that I would like to check in somewhere ... but they break my last build of HuC. For HuC, my original thoughts had been towards a "linker" of sorts, which would exclude the unused library functions, and magically "compress"... but when you see how the paging is in place, that becomes a lot more challenging that you might think. Since 8KB can fill up quickly, one would also need to know in advance how large each of the functions is, in order to "fit" it into a bank... and all this stuff is possible by hand, but so much more difficult programmatically. But in the same way, a set of pre-written assembly-language functions to include when convenient would be very powerful. Another challenge over the years has been how the startup.asm (and other library functions) has tried to be comprehensive and include a bunch of things - but that over time, these functions have been changed, breaking builds of older code. It's for this reason that Chris Covell took to using "non-standard" versions of many of the library functions. Or put another way, his code took a "specific version" and changed the name in order to prevent name conflicts and ensuring rebuildability across versions of the assembler. A few days after I had discussed this with him (in order to get a build to work), I realized the wisdom of his approach... But sure, any code availability is good.
|
|
|
Post by elmer on Sept 29, 2021 15:34:08 GMT
As for assembly development moving forwards ... that's a good question. There are still some overlay and startup-related changes to ISOlink and PCEAS that are specifically targeted at assembly language development that I would like to check in somewhere ... but they break my last build of HuC. I *think* that I can *probably* just abandon the deep changes that I was making to the HuC overlay and startup system, and yet still manage to merge in my latest ISOlink and PCEAS updates with the changes that Turboxray has been making in his fork. If I can bring my github project up-to-date with Turboxray's latest, then I'll have the chance to remove that darned GPL'd getopt that he merged in from Mooz, and replace it with one of the many getopt alternatives that don't pollute the codebase with GPL licencing. But in the same way, a set of pre-written assembly-language functions to include when convenient would be very powerful. This seems like the easiest solution to me, especially since Uli already implemented the base functionality for it, and used it for his malloc/free library. It would seem to be a good idea to put most of HuC's existing library into asm modules that you can pick-and-choose from, rather than having the current monolithic block of library code in the 2 (or 3) lib banks. Then again, I've seen such resistance from the older HuC developers to there being *any* changes to the base system that I don't know if that would fly with the userbase. Another challenge over the years has been how the startup.asm (and other library functions) has tried to be comprehensive and include a bunch of things - but that over time, these functions have been changed, breaking builds of older code. It's for this reason that Chris Covell took to using "non-standard" versions of many of the library functions. Or put another way, his code took a "specific version" and changed the name in order to prevent name conflicts and ensuring rebuildability across versions of the assembler. A few days after I had discussed this with him (in order to get a build to work), I realized the wisdom of his approach... But sure, any code availability is good. From my POV, startup.asm and the MagicKit libraries provide a great set of assembly language source code for both HuC developers, and for new assembly-language developers, to both take a look at and learn from. But as an experienced ASM developer, I find that startup.asm does too much, is far too hard to read, and it locks you into a very "HuC" style of development. Getting rid of it was one of the first things that I did when I started writing PCE code.
|
|
|
Post by turboxray on Sept 29, 2021 18:41:31 GMT
Yeah, elmer and mooz were working independently on a deflemask engine. I reached out to both, and both were supportive. I had access to both sources, but in the end I had like a solid 2 weeks to write this.. so I just started from scratch. For the version I was supporting, which I forget the number, it's pretty high compatibility rate. I implemented all FX and options (the only issue I was working out was weird edge case for manual pitch slides). Some older songs didn't work with my intermediate converter to HuTrack format, so I just simply loaded those songs in the deflemask version I support, and re-saved them. Deflemask is fine and all, but there's too much weird edge case logic that shouldn't be there - and I dislike covering that in pce side code of things. At some point I want to fork off the player so that it is its own thing. I implemented Fast Track 2 style compression on the pattern data entries, which kept the size pretty small and it's fast to decompress. Anyway, it works and I'm pretty happy with it.. but the sacrifice of writing it as as fast as I could.. is that the source isn't as clean and pretty as I would like. It definitely needs a refactor so as to be more readable/maintainable.
Michirin helped out in finding weird edge case behavior, and she provided lots of songs for me to test out.
Huc stuff:
I reverted back the getopt inclusion from Mooz's fork. Though it was more because it broke something in the command line args (that he wasn't using, so he didn't encounter it). I think he might have fixed it by now. I should have tested that further.. scratch that - there needs to be some test scripts so I wouldn't have to do manual regression testing hahah. Attach it to a pipeline/policy. As for HuC, over the past year-to-date I've been working on making it more modular. Making it so that it's easier to include assembly data/code and with easy 'don't care get in where you fit in' memory management (at leas the rom side). This allowed for breaking up the fixed library code to be more modular. One of my biggest pet peeves with HuC is that if you want to use a different set of graphic/map/sprite routines, it's a pain to replace it. A simple include won't do it. I've solved a lot of that problem with some updated logic, but there's some busy-work to redo the startup.asm and the fixed-libs associated with it.
elmer if you want to bring in my changes, let me know first. I think I have stuff in my 'dev' branch that I haven't bothered to put in 'main' yet. Once the fixed-lib thing is cleaned up, and has easy interfacing for new modules/libs, I was then taking the approach that a group of libs for different type of game designs would help tailor performance. Rather going with a one-size fits all library.. have one that focuses on performance for.. platformers, shumps, RnG, overhead, etc. I also experimented with 24bit pointer support. While I didn't change the compiler code to support it, I did make some built in funcs that would store it as a char and int. I did that with the creation of a 'macro' fastcall function type. It will call an asm macro rather than JSRing to a mapped asm func.
On the PCEAS side of things, 'proc' needs some upgrading. HuC uses 'proc' directive, but it has arbitrary limitations like no data defines inside it, no includes inside, etc.
Anyway, getting 'HuTrack' deflemask music engine working smoothly, with including songs/etc, provided a lot of logistical challenges. I didn't want to go the route where I had to "compile" the music into some weird HuC c formatted thing. I wanted it to be the same lib and method as the ASM version. I eventually got there, but I gained a few ideas of how to do this with other stuff. I like working on HuC. I know there's been some gripes about things changing in the newer versions, etc. If that means there needs to be a new fork with a new name, then I'm fine if that's what it takes to keep people happy. But I do have a laundry list of things I'd like to see in HuC 4.0.. or rather TGDK haha (if you like trends). There's been a LOT of dev activity lately with SGDK (Genensis) and recently a boom in activity for GBDK (Gameboy). PCE should be a part of that! HuC shouldn't be an impediment for coding in C on the TG/PCE. You shouldn't have to fight with it. It should have some nice in-the-box optimized options for game designs. And there *needs* to be decent code examples bundled with it that shows how to approach and optimize your design.
(I probably have some typos in here because I'm in a rush to get ready for work.. I'll edit later)
|
|
|
Post by dshadoff on Sept 30, 2021 0:14:59 GMT
I mostly agree with elmer.
startup.asm was written specifically as a "universal system initialize and include library", but the expectation was that advanced C users would grow out of the system and start writing in assembler, and would like to understand where to begin. That's why it's heavily-commented. It's true that there's a lot of #ifdef stuff though, and that's an artifact of dual-boot. Again, intended as a template, and if somebody were to read a *.lst output, they'd see what was actually needed for that version of code. It was expected to be pulled apart when writing assembler. (But I guess I never explicitly wrote that down)
Now I am thinking that it might be interesting to write a game in assembler... although I have a few projects to finish off before I would start something like that. But as is written above, if I started writing a game, I'd probably end up writing tools to fill the gaps to make it easier to write a game...
|
|
|
Post by DarkKobold on Sept 30, 2021 16:37:35 GMT
This really should be split into a separate topic.
|
|
|
Post by elmer on Sept 30, 2021 17:27:15 GMT
This really should be split into a separate topic. Yes, at this point we're so far off-topic that it probably should! elmer if you want to bring in my changes, let me know first. I think I have stuff in my 'dev' branch that I haven't bothered to put in 'main' yet. I'm a little ahead of you here ... I had already merged your changes into my gihub repository before you posted, and since then I have worked-around a couple of build problems that you've probably also fixed in your Dev branch. I have now also checked-in the most-critical subset of my changes to ISOlink and PCEAS, and those changes shouldn't break HuC this time. When I left things, I was modifying HuC to use the directory structure that I have added to CDROM ISO builds, and I was also changing the HuC startup to get around the weird initial execution address of $4060, and the limit of 32KB for the ISO boot code ... but I have now abandoned those changes because there are a lot of non-obvious interactions going on in HuC's startup that were causing things to break. For assembly-language CDROM ISO developers, PCEAS is still limited to building a 32KB-max initial program, and to starting execution at the HuC address of $4060 ... but using ISOlink with the "-ipl" option lets you get around those issues, and to build an ISO with lots of overlay programs and data files. FYI, the CDROM directory that I have added to the ISO is actually loaded into PCE memory by Huson's IPL program on boot, and it can be copied to wherever-you-want-it in memory when your application program is run.
|
|
|
Post by DarkKobold on Oct 1, 2021 22:37:30 GMT
I think that turboxray has already taken over as the person to talk to about new updates in that area, especially since he has already done his own work on a Deflemask player (and other exciting new stuff). Yeah, turboxray already has a working deflemask player, with sampled SFX playback. The whole of Jessie Jaeger's soundtrack is already in game and using his player. There's a few things to fix, but it's near ready for prime time. We don't talk very publicly about it, because there really hasn't been a whole lot of activity or interest when I talk about Jessie here. Also, I did ask spenoza to split this thread off. HuC development is a big topic, and shouldn't get buried in a thread about SotN. <script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by DarkKobold on Oct 1, 2021 22:40:56 GMT
I guess it's time to start talking about assembler development then. (and any other tools etc.) I do believe that there's still a bright future for further HuC development, and that HuC itself is an absolutely amazing way for folks to get started in game development on an old platform like the PCE ... but yeah, IIRC you and the other creators of HuC envisioned it as a path for folks to started, and that new developers would then transition into assembly language development once they needed to do more than HuC provided. I think SGDK and GBDK have shown that a decent development environment in C does wonders for the homebrew community. Further, I'm pretty sure very very few devs move from C to ASM after using these development kits. Programming in C for a console really doesn't prepare you to code in assembly for the same console. So, HuC or TGDK really should be a self-contained, fully equipped game creation system.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by dshadoff on Oct 1, 2021 22:57:52 GMT
Well, my experience up to that point was that people who program in assembler, do so because of the constraints of the environment they were using before.
As for me (and many many others), we learned BASIC first, but it was too slow and restrictive. I was studying assembler within 3 months of getting a computer. 'C' is already fairly close to assembler, but apparently not close enough for many people. Our thoughts (whether right or wrong) were that people would view the *.lst output of their build, in an effort to figure out how to speed it up, or use less space.
While 'C' is convenient and somewhat close to the machine, it will be hopelessly slow (and large) code on the PC Engine, if 16-bit arithmetic is considered a basic expectation for most everything. But it can be useful for writing code faster than assembler, and I'm sure HuC can be improved - as long as people realize that there are limits to what it is capable of without assembler.
|
|