|
Post by dshadoff on Oct 8, 2021 19:25:02 GMT
As far as I understand the history of HuC/PCEAS ... PCEAS and the MagicKit libraries were created first, and used for some time, and then HuC was created to make things easier for new programmers to get started, and it was built to use the existing MagicKit library code. Is that correct? From the looks of things, .proc/.endp was added to PCEAS very late on, primarily for HuC, so that HuC games could generate lots of banks of code easily. As far as I can see, the old MagicKit libraries were never modified to use .proc/.endp, which is why they're a monolithic chunk of code that isn't modular and easily selectable/replacable. I believe it was VERY late. I actually don't recall them being discussed, so it might have been just as my involvement was on the decline. The concept would have been that a PCEAS developer would want to be in charge of his memory map and reduce page-outs for more common routines (which he would already know). But a HuC user wouldn't necessarily know. And a you know, you would never change the function of an existing mnemonic, because assembler programmers would curse you until the end of days. But it would have been normal to create a MACRO to encapsulate it, or a pseudo-op (I'm not sure which one you found, as I never used this).
|
|
|
Post by dshadoff on Oct 8, 2021 19:31:22 GMT
On the one hand, discussion of assembly is critical to improving HuC and compiler results. On the other hand, discussion of assembly isn't necessary for someone simply developing a game using HuC. This is the point of HuC, is it not? Fair statement. But we were discussing improvements as I recall. The point of my comment was that - during development - if you find that "something" is causing you issues, you will still need to identify which "something" is doing that, even if your only recourse is to avoid doing that "something". Then, discussion of improvement of that "something" requires one level deeper of analysis than simply "X doesn't work"; it requires some explanation of what aspect is failing you, or in what way it is deficient. The more information which can be provided, the more responsive I find people to be. But you're completely correct, one can develop a game using HuC without knowing or discussing assembler.
|
|
|
Post by elmer on Oct 8, 2021 19:54:48 GMT
I don't use proc in PCEAS, but from my TASM x86 days.. "proc" facilitated not only defining a function, but also aided in passing parameters (like a C function) via built in macro. On the PCEAS side, proc needs some upgrades to allow define and include (which would go a long way for HuC). In PCEAS, .proc/.endp just mark a chunk of code (with a name) that can be relocated into an automatically-chosen bank. There is no parameter passing as part of the definition, and the method of parameter passing is not the concern of .proc/.endp. I'm not sure what you wish to accomplish by putting an include inside a .proc/.endp, because from my POV, the power for creating optional libraries is going to come from putting procedures *within* include files, and then choosing which set of library includes to use in a particular project. Hopefully you don't mean the fixed lib bank. Because that's a bad idea haha. That bank needs as much free space as possible. I agree that it needs more space, we just disagree (I think) about how to achieve that goal. I specifically want to get subroutines, either unused library code, or code that doesn't actually need to be accessed more than a dozen times per frame, out of what has traditionally been the "fixed lib bank", and into other banks. The trampoline code that replaces them is only 18-bytes-per-routine for HuC, and only 10-bytes-per-routine with the replacement code that I am currently thinking of using. Putting all of the code trampolines into bank 0 makes then permanently accessible, frees up the trampoline bank that is currently 80-90% wasted in HuC, and it also frees up an MPR page for more-useful work. Perhaps it would help to understand that even though I believe that it would be beneficial to apply this concept to HuC and the MagicKit libraries, my primary interest in doing this is for my own assembly-language code, which doesn't use either HuC or the MagicKit libraries. I am trying to be able to use PCEAS to organize PCE memory closer to the way that Falcom did in the LoX games ... so MPR7 for the permanent core "engine" code and trampolines, and MPR6 for paged code in .proc functions. <edit> Changed "bank 7" and "bank 6" to "MPR7" and "MPR6".
|
|
|
Post by dshadoff on Oct 8, 2021 20:10:04 GMT
When you say "bank 7", do you mean $C000-$DFFF, or $E000-$FFFF ?
|
|
TheOldRover
Deep Blooper
They see me codin', they hatin'
Posts: 26
Fave PCE Shooter: Lords Of Thunder
Fave PCE Platformer: FX-Unit Yuki
Fave PCE Game Overall: One that isn't out yet ;)
Fave PCE RPG: Cosmic Fantasy 2
|
Post by TheOldRover on Oct 8, 2021 22:49:19 GMT
Sorry to pop in late but I figured I'd add my own two cents to this whole soup.
I've done a few rather huge games in >99% HuC, using very little inline assembly. On top of that, they were all built on Denki. I honestly don't think that using assembly to make a game is necessary at all. It all comes down to the skill and tenacity of the developer. Writing complete, complex games in assembly language takes ages. Hell, that's why higher-level compilers were first developed in the first place... to get AWAY from coding on the metal, to make the development process more efficient. With that in mind, it's always a better idea to make sure that the higher-level compilers are as effective as possible rather than just using the same old cop-out of "LRN ASM BRUH", especially when the overwhelming majority of purists have never made a single game, let alone anything as complex and complete as Cleo.
HuC may have its faults but it's a beautiful system to the user.
|
|
|
Post by spenoza on Oct 9, 2021 0:17:41 GMT
Well, here’s another question, then. If you construct a game in HuC and don’t it is too slow or uses too much memory, is cleanup of bulky ASM something a more ASM-oriented developer could reasonably assist the original developer with? I have found that good designers aren’t always good coders and vice versa. So it makes sense for a game designer to want to work with HuC.
|
|
|
Post by dshadoff on Oct 9, 2021 0:32:40 GMT
Well, here’s another question, then. If you construct a game in HuC and don’t it is too slow or uses too much memory, is cleanup of bulky ASM something a more ASM-oriented developer could reasonably assist the original developer with? I have found that good designers aren’t always good coders and vice versa. So it makes sense for a game designer to want to work with HuC. I have strong opinions on this... It could be possible for somebody else to come in and fix it, if the problem is not large in nature. But it is also not reasonable to assume that this will actually happen. First, this type of problem is often structural in nature, and would not fit into the category of "not large in nature". Secondly, higher-skilled programmers are usually busy on their own projects, and honestly, looking at somebody else's code to size up the problem then make adjustments is likely to leave both programmers unhappy at the conclusion... unless they were working directly with one another from the very start. I am firmly of the opinion that the original programmer is best off learning those critical skills for themselves - it's a great feeling of accomplishment when it happens, and the ordeal leaves them a better programmer, with a better overall toolset.
|
|
|
Post by spenoza on Oct 9, 2021 0:38:16 GMT
Oh, I don’t mean to suggest it would be very satisfying, at least for the latter party, to come in after the fact and basically perform “clean up” on someone else’s work. I agree that a team would be much better.
|
|
|
Post by elmer on Oct 9, 2021 0:45:39 GMT
When you say "bank 7", do you mean $C000-$DFFF, or $E000-$FFFF ? Whoops, sorry ... I wrote "bank" there instead of "page/MPR", but you understood what I meant ... In this case, for assembly-language work, and definitely not for any potential changes to HuC or MagicKit ... yes I really do mean putting the permananent support code, ISR vectoring code, and .proc trampolines in MPR7, i.e. $E000-$F000. And "yes", I do also understand that we've not traditionally relied on doing that on the PCE because the System Card CD-ROM BIOS usually lives in MPR7. In my case, I believe that it's time to move passed the limitations of the old System Card BIOS, in the same way that a number of the PCE developers in the 1990s did once Hudson released their "fast" CD-ROM library code that was used in LoX2, Anearth, and various games that were created later on in the PCE's life.
|
|
|
Post by dshadoff on Oct 9, 2021 0:48:08 GMT
That's fine, I've also occasionally had thoughts of replacement System Card... just wanted to be clear on what you were suggesting.
|
|
|
Post by turboxray on Oct 9, 2021 0:55:12 GMT
@ the pairing thing..
I think such a pairing could work, assuming they like collaborative work.
But yeah, it honestly comes down to the individuals - what they get out of it. If you have ASM skill/experience, but not a lot of time.. or just don't want to take on a whole project by yourself, a collaboration would be a great option. And on the flip-side, someone might be about the big picture, and design, and hates the tediousness of optimization/asm/etc. Why not bring those two talents together? Would also be optimal to have a team of the main programmer, auxiliary/asm programmer, and game designer/artist/musician. I think the ZPF team make-up is like that?
|
|
|
Post by dshadoff on Oct 9, 2021 14:26:42 GMT
HuC is great for proof-of-concept and performing well-understood tasks; I use it myself this way. Time-critical things, or special-hardware-access (such as writing to Flash memory) need special handling which falls outside the realm of HuC capabilities... in cases like these, I have written the overall program in HuC and fleshed-in the special pieces as inline assembler.
One of the things that we realized early on, was that HuC can't be all things to all people... not just in its current form, but perhaps ever. So there will always be special capabilities for which there is no library function; this has traditionally been the case for development through the 80's to the era of operating systems with pluggable drivers (well beyond the capabilites of this hardware).
In my case, it was writing back to the Flash memory where the program resided; for others, it could be accessing a special controller or a sound chip on a custom HuCard and so on... For those special things - emergent technologies, special 'new' algorithms, and so on, inline assembly can help to solve problems.
If I built a special piece of hardware, would I augment HuC to support that single-use thing ? I don't think so. But I would likely publish the inline assembler (which could be accessed via HuC function call).
|
|
|
Post by DarkKobold on Oct 9, 2021 16:32:35 GMT
HuC is great for proof-of-concept and performing well-understood tasks; I use it myself this way. Time-critical things, or special-hardware-access (such as writing to Flash memory) need special handling which falls outside the realm of HuC capabilities... in cases like these, I have written the overall program in HuC and fleshed-in the special pieces as inline assembler. One of the things that we realized early on, was that HuC can't be all things to all people... not just in its current form, but perhaps ever. So there will always be special capabilities for which there is no library function; this has traditionally been the case for development through the 80's to the era of operating systems with pluggable drivers (well beyond the capabilites of this hardware). In my case, it was writing back to the Flash memory where the program resided; for others, it could be accessing a special controller or a sound chip on a custom HuCard and so on... For those special things - emergent technologies, special 'new' algorithms, and so on, inline assembly can help to solve problems. If I built a special piece of hardware, would I augment HuC to support that single-use thing ? I don't think so. But I would likely publish the inline assembler (which could be accessed via HuC function call).
This seems like worrying about an extreme edge case. Atlantean, Mysterious Song, FX Yuki, Cleo's Curse, and Catastrophy don't need this to be good games. All of these use HuC in some way. You're doing things well beyond what I expect any homebrew will ever do, and if they *need* these things, then the person behind them will likely be fluent in ASM.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by dshadoff on Oct 9, 2021 17:30:26 GMT
Well, we baked it in because at one point in time, most things were extreme edge cases. And the future always brings the unexpected, so extensibility is best.
But much more relevant to the overall discussion, HuC sometimes generates some unacceptably slow/large code. Inline assembly - if you know how to use it - can be used to make better replacement code. I have also used it in this way.
|
|
|
Post by DarkKobold on Oct 9, 2021 18:30:54 GMT
Well, we baked it in because at one point in time, most things were extreme edge cases. And the future always brings the unexpected, so extensibility is best. But much more relevant to the overall discussion, HuC sometimes generates some unacceptably slow/large code. Inline assembly - if you know how to use it - can be used to make better replacement code. I have also used it in this way.
I agree with that. The question I have for the general community is whether it's worth fixing HuC to be less bloated, or just expect programmers to learn assembly. If the latter is the answer, you have to just expect fewer, less intense, and smaller projects, because SGDK and GBDK have shown that most people who want to make games don't really want to dive into assembly.
Further, if someone wants to port their SGDK code over, they're definitely not going to want to do Assembly. They already wrote the game in C. ASM massively limits the portability of code. My next project, I'll try and compile SGDK, HuC, and PVSNESlib from the same code base. That's not going to happen if I need tons of ASM.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|