|
Post by DarkKobold on Feb 10, 2020 21:52:15 GMT
So, the #inctile thing appears broken in both versions, my mistake. The font loading issue, however, is relevant to the version elmer posted. I'll get on making our code available to you. The #inctile problem actually seems to be more similar to behavior I've seen in the past. If you ever send the wrong # of arguments to a function in HuC, the HuC code will still compile without warnings or errors. However, you will see some insanely crazy behavior when your code hits that function. I know that some C allows for variable arguments, but that generally requires the varagin key word. I think I must have left an argument out somewhere, because I can't do anything to my main overlay, without it crashing on build. The fact that its working in regular mode probably means that I'm getting away with a major error somewhere, but the code doesn't catch it. I'm not versed enough in the workings of C to know whether or not allowing a call of a function with fewer passes is intended functionality.
Also, I always delete the .iso and every .ovl in the directory before compile, so I don't actually try and play an old iso. That's happened enough for me to build around it.
|
|
|
Post by elmer on Feb 12, 2020 7:23:11 GMT
The font loading issue, however, is relevant to the version elmer posted. I'll get on making our code available to you. OK, thank you ... seeing both the code and the problem lets me figure out what is going on. The font problem is because of a change about 4 months ago that didn't get spotted because the example programs never use HuC's load_font(). It was actually a bug report (and fix) that I received on GitHub, and I applied the change without much checking. The bug report was actually mistaken, and the original code was working as-designed. I have reverted the change and put things back to the way that they were ... and Catastrophy's font loading works again. Also, I always delete the .iso and every .ovl in the directory before compile, so I don't actually try and play an old iso. That's happened enough for me to build around it. Excellent, smart move!
|
|
|
Post by elmer on Feb 12, 2020 9:59:11 GMT
So, the #inctile thing appears broken in both versions, my mistake. I think that I've tracked this down to the size of your initial overlay, and not to the #inctile itself. HuC's startup process will blow up if the initial overlay is larger than 192KB ... it will overwrite the code that is loading the initial overlay. I've fixed it now, but it has pointed out that HuC's default error message when running SCD games on an non-SCD System Card, actually got broken at some point. I'll make you a new build for testing tomorrow/today ... it's late.
|
|
|
Post by DarkKobold on Feb 12, 2020 18:02:00 GMT
So, the #inctile thing appears broken in both versions, my mistake. I think that I've tracked this down to the size of your initial overlay, and not to the #inctile itself. HuC's startup process will blow up if the initial overlay is larger than 192KB ... it will overwrite the code that is loading the initial overlay. I've fixed it now, but it has pointed out that HuC's default error message when running SCD games on an non-SCD System Card, actually got broken at some point. I'll make you a new build for testing tomorrow/today ... it's late. I feel dumb now, because I've seen that restriction before. I don't think you can code around my dumbness.
|
|
|
Post by DarkKobold on Feb 13, 2020 3:52:41 GMT
CODE $A000-$BFFC [8189] BANK 1E 8165/ 27 CODE $A000-$BFE4 [8165] BANK 1F 2831/5361 CODE $A000-$AB0E [2831] BANK 20 1206/6986 CODE $8000-$84B5 [1206] ---- ---- 238K 26K
TOTAL SIZE = 264K
Thanks, no need to do any fixes. I just split things properly. This is a frustrating bug though - why is it starting a new bank?
|
|
|
Post by dshadoff on Feb 13, 2020 4:44:03 GMT
The font problem is because of a change about 4 months ago that didn't get spotted because the example programs never use HuC's load_font(). It was actually a bug report (and fix) that I received on GitHub, and I applied the change without much checking. The bug report was actually mistaken, and the original code was working as-designed. This sounds like the one I submitted... Just out of curiosity, what was wrong with the fix ? It may be that there is still a problem (the one I identified), but the proposed fix broke something different, which I didn't notice... Dave
|
|
|
Post by elmer on Feb 13, 2020 5:27:19 GMT
I feel dumb now, because I've seen that restriction before. I don't think you can code around my dumbness. Ah ... but what you were doing is NOT dumb. Having some weird size limit on the first, and only the first, overlay is what I'd call "dumb". I can see how it happened ... but it really is something that should be fixed, it's not difficult. OTOH, the task has completely snowballed, and now I'm rewriting most of startup.asm, and so it'll be another few days to get a stable fix. TOTAL SIZE = 264K Thanks, no need to do any fixes. I just split things properly. This is a frustrating bug though - why is it starting a new bank? You really need to add a double "-v" to your CD build script so that you can get listings and more information. Suprisingly ... doing that points out a pretty big hidden error in building one of your overlays (when it goes over 256KB). I have no idea what is going on, and it will have to wait a bit until I fix the current problem.
|
|
|
Post by elmer on Feb 13, 2020 5:43:41 GMT
This sounds like the one I submitted... Just out of curiosity, what was wrong with the fix ? It may be that there is still a problem (the one I identified), but the proposed fix broke something different, which I didn't notice... Yep, it was that fix that broke things. It's because your fix was to make the HuC's load_font() act like the MagicKit load_font, which is used to create a character set from a monochrome bitmap font. In actuality, the HuC load_font() is there there to upload a 4-bpp character set that is created using #incchr, and not a monochrome bitmap font. So that's why the Catastrophy font loading broke with the change, and why I've reverted it. The MagicKit version of load_font is used in HuC's load_default_font(). All of this takes me back to watching "Soap" in the 1980s ... "Confused? You will be, after watching this week's episode of Soap!"
|
|
|
Post by dshadoff on Feb 13, 2020 6:48:30 GMT
Hmm... I'll have to go back and look at that with this in mind, and see what's going on. The "fix" was not to the top layer of what was being called, so there may still be something wrong, somewhere in the layers.
At the very least, the library should have comments about what's a 4-bit font versus 1-bit. (I know I was calling with a 1-bit font, but I felt certain I was calling a function which dealt with this format...).
|
|
|
Post by DarkKobold on Feb 13, 2020 7:24:51 GMT
I feel dumb now, because I've seen that restriction before. I don't think you can code around my dumbness. Ah ... but what you were doing is dumb. Having some weird size limit on the first, and only the first, overlay is what I'd call "dumb". I can see how it happened ... but it really is something that should be fixed, it's not difficult. OTOH, the task has completely snowballed, and now I'm rewriting most of startup.asm, and so it'll be another few days to get a stable fix. TOTAL SIZE = 264K Thanks, no need to do any fixes. I just split things properly. This is a frustrating bug though - why is it starting a new bank? You really need to add a double "-v" to your CD build script so that you can get listings and more information. Suprisingly ... doing that points out a pretty big hidden error in building one of your overlays (when it goes over 256KB). I have no idea what is going on, and it will have to wait a bit until I fix the current problem.
I think that "keep the first overlay under 192kB" isn't totally unreasonable, and there are probably bigger fish to fry with HuC, like why can't it merge the "Constants" bank with a DATA bank? It's wasting an entire 8kB on about 200 constants. Why does it have to include the default font? Or the mouse libraries? Or the graphics drawing ones? There's so much wasted space, I bet with options, it would be possible to get the default stuff down to a single bank. It's only taking around 75% of each of those first 2 banks anyway. I guess the next step would be for me to dig into the compiler, but I'd be so out of my depth.
|
|
|
Post by elmer on Feb 13, 2020 21:30:05 GMT
I've fixed it now, but it has pointed out that HuC's default error message when running SCD games on an non-SCD System Card, actually got broken at some point. Uli broke this back in 2014 when he moved a couple of only-used-once initialization functions from LIB1_BANK into LIB2_BANK. Since both banks are loaded on startup, that really should have been OK, but it wasn't. It really points out the need to do some cleanup in startup.asm (which is common for older code). There's so much wasted space, I bet with options, it would be possible to get the default stuff down to a single bank. It's only taking around 75% of each of those first 2 banks anyway. Yeeks ... my apologies for the typo in my previous message, what you were doing was NOT dumb! Sure, there could be some more granularity in HuC's functions, and the constants thing is definitely an annoyance that should be fixed ... but understand, you're talking about saving a couple of banks, maximum. There's no magic solution here. You're getting excellents results out of what is an entry level programming system ... but there is a *lot* of wasted space in your compiled HuC code and graphics, and there's not really an easy way around that.
|
|
|
Post by gredler on Feb 13, 2020 22:34:28 GMT
There's no magic solution here. You're getting excellents results out of what is an entry level programming system ... but there is a *lot* of wasted space in your compiled HuC code and graphics, and there's not really an easy way around that. When I heard your were taking a peek at the game I was hoping that you were going to have feedback for low hanging optimizations we may be able to make - I wouldn't expect a first effort that is basically a shot in the dark to have optimal execution. For the graphics side I think one low hanging item is auditing each png (and remaining pcx from before the transition) to be reduced color count - promotion by default always exports with 16 palettes. Was there anything else you saw that I could help DK with from the art side of optimization?
|
|
|
Post by DarkKobold on Feb 14, 2020 0:13:31 GMT
I've fixed it now, but it has pointed out that HuC's default error message when running SCD games on an non-SCD System Card, actually got broken at some point. Uli broke this back in 2014 when he moved a couple of only-used-once initialization functions from LIB1_BANK into LIB2_BANK. Since both banks are loaded on startup, that really should have been OK, but it wasn't. It really points out the need to do some cleanup in startup.asm (which is common for older code). There's so much wasted space, I bet with options, it would be possible to get the default stuff down to a single bank. It's only taking around 75% of each of those first 2 banks anyway. Yeeks ... my apologies for the typo in my previous message, what you were doing was NOT dumb! Sure, there could be some more granularity in HuC's functions, and the constants thing is definitely an annoyance that should be fixed ... but understand, you're talking about saving a couple of banks, maximum. There's no magic solution here. You're getting excellents results out of what is an entry level programming system ... but there is a *lot* of wasted space in your compiled HuC code and graphics, and there's not really an easy way around that. A few banks is the difference between fitting in a few special moves, the extra enemies in each area, or not... I'm not trying to completely optimize this, but things like seeing a few extra kB free (especially for the constants glitch) would really allow for some extra content. I've already split the Beat'em up into 2 overlays, one for loading, and one for playing. I'd rather not split it again for the 2 play styles. But... if I have to, I will. Also, I kinda dislike the "entry level programming system." HuC does what it needs to, to create great, playable games. That's all it needs to do. Entry level seems so dismissive, when really, its absolutely fantastic, and aside from relying on outside things for music/sfx, its a complete package.
|
|
|
Post by spenoza on Feb 14, 2020 2:22:29 GMT
I suspect that “entry level” comment is comparative. Back in the day it was assembly or bust. I mean, BASIC existed, but.... ugh.
|
|
|
Post by turboxray on Feb 14, 2020 17:00:14 GMT
Also, I kinda dislike the "entry level programming system." HuC does what it needs to, to create great, playable games. That's all it needs to do. Entry level seems so dismissive, when really, its absolutely fantastic, and aside from relying on outside things for music/sfx, its a complete package. I don't think it's dismissive. If anything it's accurate, as well as potentially annoying in execution at times hahah. As-is, HuC pretty much fits the definition of entry level on the PCE. I mean, what else is there? That's not to say you can't patch and prop up HuC, as well as push it to its limits to create stuff, but it's still has a lot of limitations (and not just cycle/counts or direct speed either). And those limitations are quite frustrating from an assembly environment point of view too. To me, it's the library system that is the biggest limitation. Especially graphics related, it tries to do everything (which is great for experimenting) - but it can't lock down performance because of it. The inability to easily choose your library/libraries in having multiple choices, is what makes HuC entry level. A C developer should be able to choose what library and what sections of a library to tailor to their needs, without having an advance level of understanding of assembly and the underlying environment. That would be a start.
|
|