|
Post by theoldman on Jun 22, 2018 18:25:55 GMT
Ah. Okay. Assuming the rom screenshot is using png and stm graphics, then there appears to be an off-by-1 error in the graphics conversion. That area you pointed out as errors? Note that for each row of tiles, it increases by 1 row of pixels. Ie, it's 1 line of pixels for row 1, 2 lines of pixels for row 2, etc. Something is off by 1 count when creating the tiles, apparently. Also (and I'm not sure how tile_ex() handles things), each row isn't wrapping; you may need to use 2 lines for each row to get it right (1 for the left side, 1 for the right).
............................................................................................. I'll be busy this weekend, but here late at night.
I grabbed the zlib and libpng sources, so hopefullly we can come up with something to do the png->pcx conversion correctly. Once that's done and you don't have to rely on ProMotion to do it, we will talk about what you want as a workflow vs. what you can live with
============Edit=================
I went back and used the .pcx and .fmp stuff in the file. That first set of coordinates is in pixels, not tiles. Should be (0,0)...(0, 16)....(0,32) up to (0,224). Looks nice on my end, except for the blnak tile at the beginning. Not sure it's right order, but it looks okay.
Try that sequence off coordintes on your end and see what happens...
|
|
|
Post by elmer on Jun 22, 2018 23:02:00 GMT
For the purpose of posting on the forums I did a find/replace on .png to .pcx and .stm to .fmp Sorry for the confusion! Naughty boy for confusing the issue like that, and double-naughty boy for ignoring the advice that Uncle Elmer PM'd you!!! You used #inctile_ex without really thinking about it, and got bitten in the ass. The problem is that you created a bitmap image, using 16x16 tiles, with different palettes, one palette per line of tiles, and then converted that image into a tilemap ... which added a new blank tile at the beginning of the tileset. That pushed the tileset one tile to the right in the 256x256 tileset image PNG/PCX that you saved, and meant that you then had 17 tiles using the 1st palette, and 16 tiles using each of the other palettes. So, in the tileset image, the palettes used by each 16x16 tile are ... 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15
But when you wrote your #inctile_ex command, you've only declared the first 16 tiles as using palette 0, and not the first 17 tiles. So everything gets an off-by-one error in the palette number for the last tile in a row, and your map doesn't display properly. Now ... actually trying to fix the #inctile_ex line in your source code isn't going to work, because you've now got tiles in the same palette split on multiple non-rectangular lines, which means that you need to define 2 rectangular regions (15 tiles on one line, and 1 tile on the next line) for each palette. Which means that you'd need to define 32 regions in the #inctile_ex, which isn't going to work because it only supports 16 rectangular regions at most. Now, if you'd just done what I advised, and used #inctile, and then defined your own lookup table for the palettes, then everything would have worked. That looks something like this ... #include "huc.h"
#incbin(levelmap,"pce_tilemap_palette_tests.stm"); #inctile(leveltiles,"pce_tilemap_palette_tests.png"); #incpal(levelpal,"pce_tilemap_palette_tests.png");
const char leveltilepals[256] = { 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 0<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 1<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 2<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 3<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 4<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 5<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 6<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 7<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 8<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 9<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 10<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 11<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 12<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 13<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 14<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4, 15<<4 };
main() { set_map_data(levelmap,16,16); set_tile_data(leveltiles,256,leveltilepals,16); load_tile(0x1000); load_map(0,0,0,0,16,16); load_palette(0,levelpal,16); }
And then the proper output appears ...
|
|
|
Post by elmer on Jun 23, 2018 4:20:34 GMT
I agree that's a problem. But it wasn't what caused the bad display. Having a bad palette number for the left tile has no effect on the right side, where the problem was. That was due to #inctile_ex() expecting pixel coordinates for the first coodinates. (And hence the tile data starting on the wrong row of the image) Yes, #inctile_ex() needing pixel starting coordinates was the first problem in the code, as you correctly pointed out. I'm not disagreeing with that. But once that particular misunderstanding was fixed, you were still left with the tile palette number problem that I talked about in my post, which left the tiles at the right hand edge displayed in the wrong palette. gredler's code was just plain broken. But that's absolutely fine ... the documentation isn't very clear, and he's learning, and doing really well for an artist that has little experience or interest in programming. I do agree that the plain #inctile() is the way to go if you want to use all the palettes. However, constructing the palette index table is something that should not be done by hand for more than a few tiles. That's why i wrote a utility to do just that. Right now, it only reads pcx files, though. Creating the table automatically from the tile graphics themselves, is definitely the way to go. We just want to do it in different places. I believe that it is such a basic need that it should be built into HuC/PCEAS, so that everyone can use it, rather than being a separate utility that only Aetherbyte (or other experienced programmers that write their own tools) has access to. That is, tiles do not have to be in any specific order; you can have a palette 3 tile next to a palette 2 tile next to a palette 5 tile.... You get the idea. Yep, the artist/team should be free to create the tiles as they wish to maximize the quality of the graphics. Grouping tiles by the palette number that they use is just plain crazy (IMHO). The only times that I've seen the order actually matter, was when someone wanted to fix certain tiles in specific places in order to do animated tiles or tile-based parallax, or to provide simple collision/trigger information. There are 4 bits unused in each entry in the current tile-palette lookup table. That's enough to store some simple collision information for each tile. It might not be enough for more complex types of games, but it might be worth adding some simple functions to HuC to use that space.
|
|
|
Post by elmer on Jun 23, 2018 10:02:35 GMT
IMO this solution is good for a static image like the one in the example,but really a pain in the ass if you want to do a scrolling with a dynamic map. Sorry touko, I'm having a little trouble understanding what you're saying here. Which of the solutions is good, but a PITA with a dynamic map? You're an ASM programmer, aren't you? All of this HuC stuff is pretty much a waste-of-time (IMHO) if you've got the ASM skills to write your own scrolling map code. Also elmer if by using the "unused bits" you think to the palette bits in the tilemaps, it's a waste of space and cycles,in this case it's better to use a byte for 2 tiles in a separate file,easy to handle and faster. You solution is good on the pixel artist side, he can put directly(and easily) the collisions in the tilemap during the construction of the image. Even with 4 bits, you can have 16 different states, it's enough for most cases even advanced ones . Again, I don't quite understand you. The HuC library routines look up the palette to use for a tile from the 256-byte array that you tell it about in set_tile_data(). But each byte only uses 4-bits for the palette, leaving 4-bits unused and wasted. We could potentially use those 4-bits to store collision or trigger information for each tile. It wouldn't use any more space, and it would only add 2-cycles-per-tile during drawing to mask out the 4-bits of collision data, which is absolutely irrelevant in terms of the cycles-per-tile-drawn. If you are suggesting that HuC be changed to lookup the palette to use for each tile from a 128-byte (2 tile-palettes per byte) array ... then that would certainly save 128 bytes per tileset (which is IMHO too little to worry about), but it would actually add cycles to the processing in order to handle the even/odd tile masking and bit-shifting. It would also break existing code, which I'd prefer not to do.
If you are suggesting that 4-bits-per-tile of collision data be stored in a separately-defined 128-byte (2 tiles per byte) array ... then that would add 128 bytes per tileset (which is IMHO too little to worry about), and it would still actually add cycles to the processing in order to handle the even/odd tile masking and bit-shifting. But it would be very easy for a programmer to work with. If you mean something different, then I'd love to hear it.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jun 23, 2018 10:44:33 GMT
For me the classic method(the one used with HUC),is the one which is good for static image,but a pain in the ass for scrolling,because in fact it's not flexible enough . There was a platformer which was developed many years ago(it was name echo) with the classic Huc technique, and was abandoned because of this flexibility problem . Of course, but it was just an advice,and not for criticizing your work ;-) Those topics are a good way to share experiences . In this case i agree with you . If i understand what you said, you are using the 4 bits of palette infos in the tilemap for collisions right ?? So, when you have to do your scrolling you must have to add the palette bits to your tilemap in VRAM right ??,and how can you tell which palette for which tile,if the palette bits are lost ?? IMO it's easy to stay with the classic scheme and having the collisions bits in an external file,you have only to care about convert an objet pixel coordinates in tile coordinates and then find the good byte in the collisions file . With the calssic method, you have to rebuild the palette bits in your VRAM tilemap,and spend more CPU cycles for extracting the 4 collision bits in your tilemap file,yeah it's not a lot of more, but a bit more complicated. and coding in ASM or with huc it's the same in a logical point of view .
|
|
|
Post by elmer on Jun 24, 2018 0:25:29 GMT
For me the classic method(the one used with HUC),is the one which is good for static image,but a pain in the ass for scrolling,because in fact it's not flexible enough. Hmmmm ... you get 256 16x16-pixel tiles, and any specific tile can use any palette. What you can't do (with any ease, and without duplication), is to display the same tile graphics in different palettes. Which is a pretty annoying limit ... but you can still make good looking graphics, you just get a lot more repetition on-screen than in professional games that use more sophisticated map systems. I believe that BlackTiger and OldRover's work on "FX-Unit Yuki: The Henshin Engine" shows just how very nice such a simple map technique can look. Those topics are a good way to share experiences. Which is a benefit to all of us! If i understand what you said, you are using the 4 bits of palette infos in the tilemap for collisions right ?? So, when you have to do your scrolling you must have to add the palette bits to your tilemap in VRAM right ??,and how can you tell which palette for which tile,if the palette bits are lost ?? Hmmmm ... your question leaves me wondering if you really understand the HuC system. When HuC writes a "tile" to the BAT in VRAM, it reads the 8-bit tile number from the map, it calculates the background CHR's VRAM address to put into the BAT, and then it looks up the tile number in a 256-byte array to see what palette number to use in the BAT. That is a very low-cost operation, both from CPU cycles, and memory usage, and each tile can define its own palette. The trick is in defining that 256-byte lookup-table array properly. At the moment, the only sane way of doing that in HuC is to manually create and type in a 256-byte array of const char data. That sucks. A saner method is to use an external program to look at the tileset, and create the array for you. But most programmers here don't write their own tools. The sanest way is to build that external program's capabilities into HuC/PCEAS itself, so that everyone can use it. And NO ... I definitely do NOT mean that you would use the palette number itself to convey collision information. That scheme is far, far too limiting, and horrible to work with. But you do have a spare-and-unused 4-bits in every byte in the lookup table that I mentioned that you could use for collision information ... if there were an easy way to add it into that table. But, I guess, in practice, that would be a bit ugly to set up, and not really give you much advantage over just using a 2nd 256-byte lookup table (one byte per tile) to get the collision information. IMO it's easy to stay with the classic scheme and having the collisions bits in an external file,you have only to care about convert an objet pixel coordinates in tile coordinates and then find the good byte in the collisions file. Are you talking about having a completely separate collision map that overlays on top of the tile map ... i.e. with one-byte for every one-byte in the tile map, and accessed using the same coordinates? If so, then "yes", that is by far the most flexible system. But it comes at the cost of doubling the size of the map data. It is all just a tradeoff between size, capability, flexibility, and ease-of-use. There is no right answer for every occasion.
|
|
|
Post by theoldman on Jun 25, 2018 21:50:34 GMT
"Everthing I've posted in this thread is 100% out of ProMotion." Okay. So it would be worth it for me to download a trial version of Promotion, so I can see what options you have for saving/exporting things. Or maybe I'll just ask arkhan to go buy a copy, since he's looking for a replacement for mappy "My effort in this thread has been to reduce opening and modifying any files that ProMotion spits out" I get that. Ideally, -I- would like to see you sending the ProMotion project file, and whomever running a batch file that extracts/generates the files they need, in the formats they need. Then you wouldn't have to worry about anything but graphics. "Yes that blank tile is only black because that is color 0 of the palette, it SHOULD be transparent (and displays as transparent in ProMotion) Maybe this would all be easier avoided if I could get Cosmigo to update ProMotion to add support for a "don't add blank tile to exported graphic" functionality,...." That's where I am having a problem, though. I can't verify ProMotion actually IS adding a blank tile. If it is adding it into the pcx, yes it's a problem. You will have to go a different route to get a pcx file, or use the png file and the new HuC. If it isn't, though, I'd like to find out how it got added originally, so we know what to avoid. The last set of files you uploaded doesn't appear to have that extra blank tile in the pcx. I'll double-check that I have the correct files; it may be me. Or it may be the way the png got exported. Or a dozen other things I haven't thought of yet. Until I know what to do to eliminate that extra tile and/or detect that it's there , it is going to be a problem. And even if we never figure out how the extra tile gets there, I now have code to read/write pcx files (and read png's). Its easy enough to write something to eliminate it
|
|