gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Oct 6, 2021 12:18:33 GMT
Just check Iwasaki's blog. There are a number of mentions, but in particular: Part 1 Part 2I got it wrong though, as iv was being developed while Ys I+II was in final testing stage, so it definitely didn't use iv (not sure about Ys IV), but most adventure games (or digital comics, or visual novels if you want to be specific) and a number of RPGs (in particular Far East of Eden II and Emerald Dragon) definitely used it. After producing the first Cobra game with "brute force" the developers realised they needed to handle loads of assets in a CD-ROM game so they invested on a high level script system to mass produce this kind of games, and the first game that used iv was Urusei Yatsura. But programmers (from Hudson and ALFA System) found that the system was actually robust enough for other other purposes(probably because PCE had a fast enough CPU and programmers in Hudson were no stranger to developing script interpreters and compilers), so they began using iv for other games such as RPGs. As mentioned by Iwasaki in the above entries 95% of Far East of Eden II was coded in iv and 4% was "Visual Assembler" (just scripts for visual scenes). I remembered reading some other blog entries that there were only very few assembly programmers in this game, mainly to write hook up codes and for support, but a number of iv scripters were assigned to each region to produce the in game events(remember that, the world map of this game was divided into many regions).
|
|
|
Post by elmer on Oct 6, 2021 19:08:54 GMT
The PCE already has an official script language called iv. Most RPGs and adventure games were 90% written in iv (at least those 1st party ones, by that I mean everything from Hudson Soft and ALFA System). Possiby not efficient enough for shooters and such, but at least action RPGs like Ys I, II and IV (don't know about III) were written in iv. Too bad not much is known about it, otherwise it could be used as inspiration on what to create as a high level interface to low level library functions. Nice find! That sounds very much like the system that they've got running underneath the hood of Anearth Fantasy Stories, although Anearth probably uses a version that has had a bunch of upgrades.
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Oct 6, 2021 19:26:03 GMT
I think considering the advance in programming languages and compiler efficiency in the recent decades iv may not be useful for creating new stuff anymore. However, if more could be known about it could help tremendously in hacking understanding existing games (in particular, to translate them, especially since we're talking about story/text heavy RPG/adventures), if only we can decompile them even if we could not retrieve the original symbols and comments(I assume the iv scripts were compiled into byte codes or something), to change something and then recompile them and insert them back.
|
|
|
Post by DarkKobold on Oct 7, 2021 3:45:48 GMT
Isn't the code generation issue more an issue of "SmallC" than the HuC library itself? forums.nesdev.org/viewtopic.php?f=2&t=20226&hilit=vbccSomeone ported VBCC to the NES, and got great code efficiency. This is the thing I don't understand about HuC. It seems like a lot of the library itself is baked into the compiler. There are some functions that you can look up as part of the library, but not all. I'm sure it's not simplistic to switch compilers, but this is apparently a very optimized 6502 compiler. <script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by turboxray on Oct 7, 2021 14:49:07 GMT
The libraries aren't baked into HuC, it's just some of the fastcall function signatures are.
|
|
|
Post by elmer on Oct 7, 2021 15:15:17 GMT
The main reason I used HuC at all and not assembly (as my NES project was) was because it seemed like it was easier to access the CD-ROM using the C libraries. CD-ROM access over raw assembly is very intimidating, at least to me. It is actually pretty easy to access the CD in assembler using the BIOS functions ... but there isn't much example code, and the trick is knowing where to load data from on the CD. HuC's overlay functionality takes care of this for developers, but until I changed ISOlink to put a CD directory on the disk, there wasn't an easy way for assembly-language folk to find out where stuff was on the CD (without writing other tools). I would think that memory usage would be more pressing, necessarily, than speed. Is it easier or harder to look at HuC through the lens of memory consumption rather than speed? You've got to remember that HuC is based of off Ron Cain's Small-C, that was itself written in approx 1980 as a proof-of-concept and a project to be published in a magazine. It was never written as a commerical-quality compiler, and compiler techniques/tools have moved on in leaps and bounds in the subsequent decades. Modern "toy" compilers, such as Small-C was at the time that it was written, are far more sophisicated today than HuC will ever be. HuC's peephole optimizer can be worked on to produce somewhat less bloated and redundant code, but it would be a LOT of work and time that might be better targeted elsewhere. Dave and the other HuC developers did an amazing job with the tools/source that they had available at the time ... but if people really want to develop games on the PCE in something C-like, then (IMHO) it might be time to look at what it would take to get a more-modern compiler to target the PCE.
|
|
|
Post by elmer on Oct 7, 2021 16:39:32 GMT
Yes, that does seem like *much* better code quality ... but look carefully ... vbcc does not like the post-increment in the loop condition too much and makes a copy of the pointers:
Much better code gets generated when slightly rewriting the function:You are still recommended to look at the listing file, and to rearrange your C code for the compiler's convenience! Apart from that, VBCC's banking abstractions aren't anywhere-near as sophisticated as HuC/PCEAS yet, but that could be worked on if someone wanted to collaborate with Dr Barthelmann, and if he had any wish to collaborate with them. Since VBCC is both closed-source, and commercially-licensed (although cheap) for you KickStarter folks, then you're really at Dr Barthelmann's mercy about using it on the PCE, and having it integrated in a usable way with the HuC library that you're used to.
|
|
|
Post by DarkKobold on Oct 7, 2021 17:45:04 GMT
Yes, that does seem like *much* better code quality ... but look carefully ... vbcc does not like the post-increment in the loop condition too much and makes a copy of the pointers:
Much better code gets generated when slightly rewriting the function:You are still recommended to look at the listing file, and to rearrange your C code for the compiler's convenience! Apart from that, VBCC's banking abstractions aren't anywhere-near as sophisticated as HuC/PCEAS yet, but that could be worked on if someone wanted to collaborate with Dr Barthelmann, and if he had any wish to collaborate with them. Since VBCC is both closed-source, and commercially-licensed (although cheap) for you KickStarter folks, then you're really at Dr Barthelmann's mercy about using it on the PCE, and having it integrated in a usable way with the HuC library that you're used to.
So, I'm not set on VBCC, it was just one example of a compiler that generates more 6502-friendly code. I'm concerned with any close source solution, not so much for the cost, as that once he gets bored, support disappears forever. If we were permanently dependent on Uli, there'd be no progress on HuC for a decade.
Like you said in your previous post, Small C wasn't meant for the big time. It's doing a great job in my games, but there's definitely room for improvement by using a more modern compiler. There's other options, like CC65, and others. Someone with more skill than myself would have to deal with the banking issues that HuC has already handled excellently. I don't know how much work it is to convert from one compiler to another.
Further, I'm not an ASM programmer. I can't look at a .lst and tell you what's going on. So, I could spend all day looking at it, but I'm not going to understand how to change my code to make it better. That said, that example is a lot different than decrementing a single variable in an array. I'd be more curious about how the compiler handles that handles the example you posted, than how the compiler handles one odd case of a loop. That said, both options are probably (?) better than Small C would have done.
I think the big question is, what's the goal here? Is it to enable people like myself who just want to write games for the system to make better games and encounter less potential lag? Or is it to endlessly remind people that ASM is better?
I'd argue C is better, due to this simple example -
vs.
I want to clarify, I'm not demanding anyone improve HuC, change it's compiler, or any of that. HuC is pretty fantastic as-is. I'm saying if people want to contribute to HuC and make it better in any way, it will be greatly appreciated by me and hopefully the rest of the community. If these threads just continue to devolve into "HuC programmers should just learn ASM" then there will never be any forward progress.
As a total aside, the GB dev servers on discord had to split, because they got so tired of the C area getting invaded by the "Just learn ASM bro" people coming in to shit on those wanting to make GB games in C.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by dshadoff on Oct 7, 2021 22:06:46 GMT
The challenge with what you're asking is that there is no such magic bullet. I don't ask people to look at the assembler in an effort to persuade them to stop using C; I ask them to look at the assembler output in order to gain a better appreciation for what it does well, versus what it does poorly.
You don't have to understand everything in order to understand something.
|
|
|
Post by DarkKobold on Oct 7, 2021 22:23:37 GMT
The challenge with what you're asking is that there is no such magic bullet. I don't ask people to look at the assembler in an effort to persuade them to stop using C; I ask them to look at the assembler output in order to gain a better appreciation for what it does well, versus what it does poorly. You don't have to understand everything in order to understand something.
I mean, there already is a magic bullet, HuC. It compiles C and allows me to make games. I'm not looking for the best compiler ever that perfectly produces optimized ASM. That obviously doesn't exist. The topic raised was how to improve this magic bullet, and it seems like the general answer is "learn Assembly." I'm trying to say that's a bad answer if we want more homebrewers to make games for the PCE.
And your logic is a bit flawed. If you use Google translate to turn English into Japanese, you have no clue how good or bad the output is. You don't know how to reformulate your English to make better Japanese, because if you compare the two different translations, they're both gibberish to you. I've been working with Tom on his music engine, and when we dig into the .lst file, it's gibberish to me.
Whereas, the basics, such as using globals, avoid passing variables, etc, are easy to communicate. I try and do that as much as possible in all my code. And, as elmer pointed out, Small C isn't great even when you do write ASM-friendly C.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by dshadoff on Oct 7, 2021 22:37:15 GMT
Well, actually, in order to talk about HuC, we ultimately come back to assembler if we talk about elements like: - memory usage - speed/efficiency - approach to specific language elements - library inclusions - bugs - debugging
Assembler is what needs to be referenced for any meaningful discussion on these topics... in order to improve the outcome. Because the assembler output is the reference by which an outcome is defined.
Assembler doesn't need to be part of the discussion when referencing topics such as: - graphic tools - ADPCM - PSG playback
|
|
|
Post by elmer on Oct 8, 2021 15:29:14 GMT
As such ... the .proc/.endp abstraction that y'all built into PCEAS/HuC is really, really powerful ... but I think that I'm going to propose/implemement a small (optional) change to make things a bit better (IMHO) for assembly-language use. OK, as usual it was pretty easy to modify PCEAS to do what I want (and to make it optional so that it doesn't break old code) ... but it does bring up a question. 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. Now, it was easy for me to modify PCEAS to put all of the .proc/.endp automatically-generated code trampolines into the first bank of the program instead of the last bank, but it took an hour or two of debugging to realize why PCEAS was not calling the trampolines when I did a JSR to a function, and that there is another pseudo-instruction named CALL that you use to access functions that are defined as .proc. My question is ... why doesn't JSR just do what this CALL instruction does? The processing for CALL in PCEAS, which is in the do_proc() function, already handles calling normal functions that aren't defined as .proc, and so it (seems) to work for all types functions.
|
|
|
Post by spenoza on Oct 8, 2021 18:57:58 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?
|
|
|
Post by turboxray on Oct 8, 2021 19:01: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).
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.
|
|
|
Post by turboxray on Oct 8, 2021 19:05:06 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? Dave is correct. It you're talking about libraries, speed, memory, etc.. anything other than simple writing some C syntax, then it's going to involve a discussion about assembly.
|
|