|
Post by elmer on Jan 13, 2020 9:25:05 GMT
But using pceas means you aren't using huc, lol. thats the issue. You're just trolling now. HuC is built on top of PCEAS, you can't seperate them. The methodology is little different to developers using binobj in GCC toolchains to include binary files into a project.
|
|
|
Post by Arkhan on Jan 13, 2020 9:35:32 GMT
No, I am not trolling. The expectation of a HuC user, IE: DarkKobold, is that they can do all their stuff using HuC.exe and not anything with PCEAS or an asm file.
That is the issue. It's a usability expectation that is implied but not delivered upon with the C functions and the things you can do with overlays.
That is literally the entire issue here that we're talking about.
|
|
|
Post by dshadoff on Jan 13, 2020 12:26:13 GMT
...To assume that anything more than the above should have been created is to assume that there was more time available, more developers involved, and more information already known about the system. In case I've not been clear enough recently ... I find what you guys did in creating HuC to be pretty-darned-amazing, even more so with the limited information and technology of the times. The existence of your work is one of the primary reasons that I am here and contributing to stuff today, without it, I just wouldn't have had the patience to develop it all from scratch myself. That doesn't mean that I agree with every design choice that was made, after all we're all different individuals with our own unique experiences and preferences ... but I love that you guys actually did make and follow through with your choices, and successfully created something that was both tough to make, and still valuable 20 years later on. I appreciate the positive feedback. It means a lot. And I don't take your criticism of any part of HuC personally; there are parts of it that I didn't feel happy about, even back then. My responses are only to provide context to why it exists in the state that it does; I'm not trying to defend sub-optimal choices as though they were/are optimal. So ... I've taken your isoLink source, and extended it just a little (the changes are fairly minimal). Since I was playing around in there, I also made a couple of small modifications to the HuC overlay loading, while trying to be careful not to break things. . . . The changes are checked into github, but I'm not going to share a "release" build unless someone indicates a specific desire for one. I'm looking forward to seeing it when you feel it's more ready !
|
|
|
Post by Arkhan on Jan 13, 2020 13:04:03 GMT
make a new thread. this ones about PyDiscmaker.
Not that elmer can see it since he blocked me.
ayyooooooo
|
|
|
Post by DarkKobold on Jan 13, 2020 18:00:53 GMT
The changes are checked into github, but I'm not going to share a "release" build unless someone indicates a specific desire for one. This is great news. I don't know if any of my projects will go over 50 overlays, but they certainly won't go over 98.
|
|
|
Post by DarkKobold on Jan 13, 2020 18:07:12 GMT
Is there a way to coax a data-only overlay with HuC in any capacity, currently? If not, the overlay process is still not as flexible as it needs to be for CD_LoadVram, and whatnot Can you provide an example of something that doesn't work in the way that it is supposed to ... or heck, even just as you wish it would? As I have said before ... I don't use HuC, so I'm a lousy person to determine what is broken, or could just be better. Uli made a *lot* of changes to improve HuC, and he provided a testsuite so that regressions and problems could be identified, even including an overlay test ... but there are no examples for data overlays. A look at the HuC source code suggests that data overlays should just be assembled in pceas with "-raw", or included as binary files if you use an external converter. Beyond that, I have no idea how they're supposed to be used. Have you ever seen any examples? What he's talking about is that HuC has a lot of useful features built in, such as #inctile, #inctile_ex #incspr, which converts the PNG or PCX format into a raw format that the TG16 understands. So, if I want to do a raw data load from an overlay, I'd need to mojo jojo it into the raw formats that I've (thankfully) been completely blind to. (Except that insane failed compression attempt).
|
|
|
Post by elmer on Jan 13, 2020 18:57:21 GMT
What he's talking about is that HuC has a lot of useful features built in, such as #inctile, #inctile_ex #incspr, which converts the PNG or PCX format into a raw format that the TG16 understands. So, if I want to do a raw data load from an overlay, I'd need to mojo jojo it into the raw formats that I've (thankfully) been completely blind to. (Except that insane failed compression attempt). I suspect that you may not have dug into the inner workings of HuC enough to realize that those HuC conversion capabilities are actually built into the assembler, and are not a part of the HuC compiler. So, unless I'm gravely mistaken, to build a data overlay that you can upload to VRAM directly from CD, all that you should have to do is create an assembly-language file "data.asm" ... .inctile "mytiles.png" .incspr "mysprites.png" ... do a "pceas -raw data.asm", and then add the resulting fully-converted "data.pce" file onto your isoLink command line. Once you get passed using the internal HuC/pceas conversion capabilities, and move onto a customized conversion toolchain, then it becomes even easier.
|
|
|
Post by Arkhan on Jan 13, 2020 18:58:13 GMT
Yeah, huc doesnt provide the means to use its own functions as intended. thats an issue.
thats THE issue really. You cant make proper use of the CD library with your knowledge even though HuC implies you should be OK.
|
|
|
Post by DarkKobold on Jan 15, 2020 3:01:30 GMT
What he's talking about is that HuC has a lot of useful features built in, such as #inctile, #inctile_ex #incspr, which converts the PNG or PCX format into a raw format that the TG16 understands. So, if I want to do a raw data load from an overlay, I'd need to mojo jojo it into the raw formats that I've (thankfully) been completely blind to. (Except that insane failed compression attempt). I suspect that you may not have dug into the inner workings of HuC enough to realize that those HuC conversion capabilities are actually built into the assembler, and are not a part of the HuC compiler. So, unless I'm gravely mistaken, to build a data overlay that you can upload to VRAM directly from CD, all that you should have to do is create an assembly-language file "data.asm" ... .inctile "mytiles.png" .incspr "mysprites.png" ... do a "pceas -raw data.asm", and then add the resulting fully-converted "data.pce" file onto your isoLink command line. Once you get passed using the internal HuC/pceas conversion capabilities, and move onto a customized conversion toolchain, then it becomes even easier.
Thanks, this is really helpful. I have a couple questions about your STM implementation:
#inctile(leveltiles,"maps/tileset_vacuum.png"); #inctilepal(leveltable,"maps/tileset_vacuum.png");
here's the code to load them: set_tile_data(leveltiles,228,leveltable,11); load_tile(0x800); Somehow, load_tile(address) also sets some flags as to where the tiles start in memory? (esp because we use 16x16 tiles) So now I replace these with cd_loadvram(int ovl_idx, int sector_offset, int vramaddr, int bytes);
How does it know where I put the tile data? How do I put the leveltable into memory? Looking at the doc, this is a far more complicated problem, because they are integrated in the same word?
MSB LSB ppppnnnnnnnnnnnn
p : Color palette (0-15) n : Character name (0-4095)
|
|
|
Post by DarkKobold on Jan 15, 2020 3:05:13 GMT
Yeah, huc doesnt provide the means to use its own functions as intended. thats an issue. thats THE issue really. You cant make proper use of the CD library with your knowledge even though HuC implies you should be OK. You're right to a degree - it'd be nice if HuC would obfusicate things like the sector load. That said, you (the programmer) still have to compile each overlay individually.
TBH, I was planning on just loading an overlay each section to load graphics, and then load the gameplay overlay. That's a lot of extra load time, but it'd be guaranteed to work.
You'd need an entire IDE at that point which held your hand in building each overlay, and whether it was just raw data or code+data.
That's a pipe dream that's entirely unlikely.
|
|
|
Post by Arkhan on Jan 15, 2020 9:46:41 GMT
Yeah, huc doesnt provide the means to use its own functions as intended. thats an issue. thats THE issue really. You cant make proper use of the CD library with your knowledge even though HuC implies you should be OK. You're right to a degree - it'd be nice if HuC would obfusicate things like the sector load. That said, you (the programmer) still have to compile each overlay individually.
TBH, I was planning on just loading an overlay each section to load graphics, and then load the gameplay overlay. That's a lot of extra load time, but it'd be guaranteed to work.
You'd need an entire IDE at that point which held your hand in building each overlay, and whether it was just raw data or code+data.
That's a pipe dream that's entirely unlikely.
Yeah, the functionality is there in asm, but huc as a whole implies you can do it from huc directly. The fact conversion stuff is asm down in the bowels of it doesnt really matter because I really thought the point of usable stuff was to avoid needing to go code spelunking. There is a mindset difference that isnt being understood by one side, I think. DK, you dont really feel like digging in and analyzing or exploring compiler and lib source, right?
|
|
|
Post by elmer on Jan 15, 2020 19:15:47 GMT
Thanks, this is really helpful. I have a couple questions about your STM implementation: Just to clarify ... HuC's overlay system has nothing do do with any of the changes that I made to HuC/PCEAS, and looking at Uli's github history suggests that it is unchanged since HuC 3.21. Similarly with the STM capability (that HuC 3.21 doesn't support) ... it is just an optional alternative to using MAPPY files, and the data produced, and the way that you use it hasn't really changed since HuC 3.21. What *has* changed is the new last parameter to set_tile_data(), which is used to tell the map functions whether you're using 8x8 or 16x16 tiles ... but you can use another HuC library call to set that. Anyway ... back to the actual question ... #inctile(leveltiles,"maps/tileset_vacuum.png"); #inctilepal(leveltable,"maps/tileset_vacuum.png"); here's the code to load them: set_tile_data(leveltiles,228,leveltable,11); load_tile(0x800); Somehow, load_tile(address) also sets some flags as to where the tiles start in memory? (esp because we use 16x16 tiles) So now I replace these with cd_loadvram(int ovl_idx, int sector_offset, int vramaddr, int bytes); For a start, the tile palette information *must* be in regular memory so that the library functions can access it when you draw tiles on the screen, so you really don't want to try loading that from CD (for now). It is only 256 bytes long, and it is easiest to just keep it as part of your HuC overlay progam. So, if I'm understanding the code and method, you would create an assembly-language file, let's call it tileset_vacuum.asm, with one line in it ... .inctile "maps/tileset_vacuum.png" Then you assemble/convert the data with pceas -raw -s tileset_vacuum.asm and the assembler will produce the file tileset_vacuum.pce and show you how much data you've created. You then add tileset_vacuum.pce to your list of files that you add to isoLink, and note which overlay number it is. To use the data in HuC ... #inctilepal(leveltable,"maps/tileset_vacuum.png");
set_map_pals(leveltable); set_map_tile_type(16); set_map_tile_base(0x800);
cd_loadvram(<your_overlay_number>, 0, 0x800, 228 * 128); You can store and use lots of different tilesets in the same overlay file by using the sector offset parameter to cd_loadvram(), but figuring out those offsets can be a PITA when you start to deal with a lot of tilesets (or other assets) in a single file. That's when developers either start using container-file formats, or you do what punch has done, and you process a list of data files and output a header file that you can include, just so that you know where data is within an overlay. Does that make sense? Heck, I'm writing this off-the-cuff from looking at the HuC and library source ... does it even actually work if you try it?
|
|
|
Post by spenoza on Jan 15, 2020 19:46:02 GMT
I want to keep this thread on Punch's PyDiscMaker and move the ISOLink stuff to a different thread, but I'm not entirely sure where to draw the line of what to split off. Punch, this is your thread. Where's the cutoff message you'd like me to carve out to a different thread?
|
|
|
Post by Arkhan on Jan 15, 2020 20:33:38 GMT
my guess would be Elmers "intimately" post and onward should be clipped out.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 15, 2020 21:09:36 GMT
I want to keep this thread on Punch's PyDiscMaker and move the ISOLink stuff to a different thread, but I'm not entirely sure where to draw the line of what to split off. Punch, this is your thread. Where's the cutoff message you'd like me to carve out to a different thread? I'm from Buenos Aires and I say kill 'em all. ...I'd say preserve all posts, and let people continue elsewhere organically if they desire. Everything discussed is also pertinent to pyDiscMaker.
|
|