|
Post by gredler on Jun 6, 2018 9:03:29 GMT
While on the subject of expanding file formats for use in HUC (png), I am curious if we will ever see another tile map generating program besides Mappy be supported? I am able to export from ProMotion to other tilemapping programs (Tiled and Construct 2), but Mappy is giving me a pain in the neck trying to open a direct export form ProMotion in Mappy.
ProMotion exports the pcx/graphical data fine, but when I try to open the .MAP file that ProMotion spits out in Mappy there are no tiles placed. When opening the .MAP in a text editor it looks so similar to one spat out by Mappy, and I haven't taken the time to load this .MAP with a ROM yet- that will be tomorrows attempt - but the .MAP wont open in Mappy.
Also, ProMotion either spits out a seprate file for each tile (ew, good luck coding 256 of those, fun task), or one 256 color indexed image. So if we import a 256 color pcx is it possible to define the 16 different palettes from that one pcx? So the first palette would be 0 through 15, and the second palette would be 16 through 32?
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jun 6, 2018 16:43:46 GMT
Touko: Thanks for the links, I'll check it out when I have time to work on PCE again (which is not likely to be soon hah), and it's good to see you here buddy. Thanks ,i find those tools really useful and easy to use .
|
|
|
Post by elmer on Jun 6, 2018 22:46:23 GMT
I used 16 color PCX files for the tutorial since... well, we're on a system that uses 16 color palettes. Some graphics editing programs are just too hastily-coded to fully support some image formats. Haha, good burn! But I have to disagree. I bought ProMotion when I first discovered it, back at version 4.0, in early 1999. It is still in development by the original author, and it has been used by numerous professional game studios. If, after 19 years of development, it doesn't support 16-color PCX files, that's not because it was "hastily-coded", it is because nobody ever wanted it to. IBM introduced the VGA standard, with its 256-color color mode, back in 1987. All of the professional Western 4th-generation (SNES/Genesis/PCE) game developers that I know of were creating their art in 256-color editors from back in the early 1990s (DPaint/DAnim), or even earlier if their art teams were Mac-based (such as those at ICOM Simulations). I used 16 color PCX files for the tutorial since... well, we're on a system that uses 16 color palettes. Yes, but the PCE has 16 different 16-color palettes for sprites, and another 16 different 16-color palettes for background tiles. Even though a single hardware sprite can only display colors from 1 palette, a group of multiple sprites, such as those that make up larger enemies, can often be improved if they use multiple palettes. That was a pretty common trick on the SNES, possible but rarer on the Genesis (because it only has 4 palettes) ... and it is certainly possible on the PCE. We created art like that by splitting the 256-color palette into 16 sets of 16-color areas, and then coloring the sprite pixels in the art to show which palette they should use on the console. ProMotion directly supports that kind of palette organization in its toolset, because professional developers were still using it in the Gameboy Advanced era (and beyond). I just don't see the advantage of creating art in 16-color files. While on the subject of expanding file formats for use in HUC (png), I am curious if we will ever see another tile map generating program besides Mappy be supported? Remember ... it's all Open Source. Anyone is free to write their own support, and then just send me a Pull Request on Github. If you're relying on me to write something for it, then that would depend upon whether anyone was ever likely to use such a feature, and could interest me in their project. If I were to look at any other package, it would probably be Tiled, because it is multi-platform, open source, and still being actively developed. I am able to export from ProMotion to other tilemapping programs (Tiled and Construct 2), but Mappy is giving me a pain in the neck trying to open a direct export form ProMotion in Mappy. ProMotion exports the pcx/graphical data fine, but when I try to open the .MAP file that ProMotion spits out in Mappy there are no tiles placed. When opening the .MAP in a text editor it looks so similar to one spat out by Mappy, and I haven't taken the time to load this .MAP with a ROM yet- that will be tomorrows attempt - but the .MAP wont open in Mappy. Mappy is very flexible, and its default settings are different from the map that ProMotion exports. Have you told Mappy that you're trying to import maps in a different format to its default? You need to edit "mapwin.ini". It is explained in the Mappy documentation in "The MAP file format" section. Also, ProMotion either spits out a seprate file for each tile (ew, good luck coding 256 of those, fun task), or one 256 color indexed image. So if we import a 256 color pcx is it possible to define the 16 different palettes from that one pcx? So the first palette would be 0 through 15, and the second palette would be 16 through 32? That is certainly how it used to be done, back in the day. I don't believe that HuC currently supports any kind of palette information for the tiles/blocks within the map data itself, just a global table for the entire map, indexed by the tile/block number. I suppose that HuC could create that table as the tiles are processed by PCEAS. Is that what you're talking about?
|
|
|
Post by gredler on Jun 7, 2018 1:04:03 GMT
Remember ... it's all Open Source. Anyone is free to write their own support, and then just send me a Pull Request on Github. If you're relying on me to write something for it, then that would depend upon whether anyone was ever likely to use such a feature, and could interest me in their project. If I were to look at any other package, it would probably be Tiled, because it is multi-platform, open source, and still being actively developed. Tiled is exactly why I was asking if anyone had seen potential for another more actively maintained application may be adopted in the future. I did not mean to imply I am relying on you specifically, but I am inevitably relying on a tools developer because changing the compiler's map file formatting is miles outside of my ability, and I was more curious how plausible that change would be. If you're asking would I prefer using Tiled or another tilemap generating application, yes I would Your answer below solves my main issue, I believe, but I will need to try it out to confirm. Mappy is very flexible, and its default settings are different from the map that ProMotion exports. Have you told Mappy that you're trying to import maps in a different format to its default? You need to edit "mapwin.ini". It is explained in the Mappy documentation in "The MAP file format" section. This is almost certainly my blockage - I will read the "The MAP file format" section in the Mappy documentation, and modify my mapwin.ini to see if I can get mappy to load my ProMotion export. That being said, would you know if the ProMotion map export format is something that HuC would accept? Related to the above question, that is something I can see being immensely productivity boosting to have if not, but if it does then heck yeah I can just go ProMotion to HuC with no mappy needed! That is certainly how it used to be done, back in the day. I don't believe that HuC currently supports any kind of palette information for the tiles/blocks within the map data itself, just a global table for the entire map, indexed by the tile/block number. I suppose that HuC could create that table as the tiles are processed by PCEAS. Is that what you're talking about? Yes I believe so. Right now ProMotion tilemap export spits out one image for each, or one image total, and a map file (pcx, map). I really am just trying to find a way to stop modifying everything in photoshop and gimp. I love ProMotion, and it seems so close to exporting turnkey assets, but I am currently required to manually assemble a seperate image for each palette of the tilemap, and their layout has to be the same order in which the combined image is imported into the mappy, which can get confusing and hairy quickly. It would be so much easier if I could carefully setup my 256 color indexes, then when I export from promotion I have a .map and a .pcx I can hand to the programmer for implementation.
|
|
|
Post by elmer on Jun 7, 2018 4:58:48 GMT
Tiled is exactly why I was asking if anyone had seen potential for another more actively maintained application may be adopted in the future. I did not mean to imply I am relying on you specifically, but I am inevitably relying on a tools developer because changing the compiler's map file formatting is miles outside of my ability, and I was more curious how plausible that change would be. I was mainly pointing out (for the first time in this new forum) that folks are completely free to make whatever upgrades/changes they want, and that I'm open to integrating other people's improvements. Generally, adding new formats is easiest if there is an obvious way to determine that they're different from existing formats. The easiest version of that is if the new formats use a different file extension, and the next easiest is if they contain some unique header bytes within the file that can be searched for. This is almost certainly my blockage - I will read the "The MAP file format" section in the Mappy documentation, and modify my mapwin.ini to see if I can get mappy to load my ProMotion export. I believe that you'll need to set ... maptype = "LW4H4A20" mapdefw = 16 mapdefh = 16 And maybe use the width/height values of "8" instead of "16" if you're using 8x8 tiles instead of 16x16 tiles. That being said, would you know if the ProMotion map export format is something that HuC would accept? Related to the above question, that is something I can see being immensely productivity boosting to have if not, but if it does then heck yeah I can just go ProMotion to HuC with no mappy needed! Could you maybe just save the map itself out from ProMotion as an image, and then use "incmap"? Anyway ... I don't think that PCEAS currently supports a ".MAP" file, but there's absolutely no reason that it couldn't read a ProMotion map as an alternative to using Mappy's ".FMP" format. But I'd rather add support for ProMotion's "Simple Tile Map" (.STM format) than its "Gameboy Advance Tile Map" (.MAP format). Are you able to save your map from ProMotion in .STM format? It would be so much easier if I could carefully setup my 256 color indexes, then when I export from promotion I have a .map and a .pcx I can hand to the programmer for implementation. Make that a .png and a .stm, and we may have a deal! I'd rather attach the new capabilities to new file formats, so that I don't break compatibility with existing game source/assets.
|
|
|
Post by gredler on Jun 7, 2018 17:44:55 GMT
I was mainly pointing out (for the first time in this new forum) that folks are completely free to make whatever upgrades/changes they want, and that I'm open to integrating other people's improvements. Heck yeah thank you! Now let's just hope a kind coder takes you up on this! I believe that you'll need to set ... maptype = "LW4H4A20" mapdefw = 16 mapdefh = 16 And maybe use the width/height values of "8" instead of "16" if you're using 8x8 tiles instead of 16x16 tiles. I wasn't able to test this last night, but thank you so much for the clear suggestion! I was going to try to research it and figure it out, so this saved me a lot of trial and error and probable frustration! Could you maybe just save the map itself out from ProMotion as an image, and then use "incmap"? Would that remove duplicate tiles and function similarly? Might be worth a try! I have ~240 tiles and about 4 palettes on my 640x224 tilemap that is currently in progress. Anyway ... I don't think that PCEAS currently supports a ".MAP" file, but there's absolutely no reason that it couldn't read a ProMotion map as an alternative to using Mappy's ".FMP" format. But I'd rather add support for ProMotion's "Simple Tile Map" (.STM format) than its "Gameboy Advance Tile Map" (.MAP format). Are you able to save your map from ProMotion in .STM format? Yes I can export as .STM, and have no attachment to the .MAP file; I had only chosen .MAP because it was the only tilemap file type with a correlation I could find between ProMotion and Mappy. My intention was that if I can get anything to go from ProMotion to Mappy I can save in Mappy as .FMP. My thought processes was just use Mappy to export data that HuC would be happy with, so I tried .MAP as it was one of the file types Mappy offers to open. I actually am not a fan of Mappy (surprise?), so if I could just export from ProMotion and omit Mappy (and gimp) that would be incredible! Make that a .png and a .stm, and we may have a deal! Definitely. I tried to get on the pc last night after hockey but literally fell asleep while setting up a simple test project in promotion to send you stuff. Sorry! No games the rest of the week so I should have the energy after work I'd rather attach the new capabilities to new file formats, so that I don't break compatibility with existing game source/assets. Sounds great to me. I do look forward to working with PNGs; if that's possible I am sure I wont be the only layman who is very appreciative!!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 8, 2018 6:24:53 GMT
When I was trying to figure out how PCEAS functions for PCX/Mappy imports worked (documentation is important ) I saw the code responsible for importing the mappy file and it was pretty simplistic, it basically selected a very specific section of the file (the tilemap) and ignored the rest. There's plenty of room for improvement there, that's for sure.
|
|
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 Jun 8, 2018 10:56:29 GMT
IMHO, it is probably more worthwhile to fix bugs already present in the compiler before adding new things. Just sayin'. If, after 19 years of development, it doesn't support 16-color PCX files, that's not because it was "hastily-coded", it is because nobody ever wanted it to. IBM introduced the VGA standard, with its 256-color color mode, back in 1987. All of the professional Western 4th-generation (SNES/Genesis/PCE) game developers that I know of were creating their art in 256-color editors from back in the early 1990s (DPaint/DAnim), or even earlier if their art teams were Mac-based (such as those at ICOM Simulations). Fine, we'll skip calling it hastily-coded (even though it is) and just call it short-sightedness. Call it what you will... it's lazy implementation. PSP has supported 1-bit and 4-bit color modes since its inception. Kind of foolish that an application designed for game art can't implement this basic functionality. Also, I don't really care what others are doing... appeals to authority don't sway my opinion in regards to proper implementation of the basics. Even though a single hardware sprite can only display colors from 1 palette, a group of multiple sprites, such as those that make up larger enemies, can often be improved if they use multiple palettes. That was a pretty common trick on the SNES, possible but rarer on the Genesis (because it only has 4 palettes) ... and it is certainly possible on the PCE. I did this in Yuki and MS2. It's not hard to do. You just have to be mindful of sprite-pixels-per-line limits. I just don't see the advantage of creating art in 16-color files. Who said it's an advantage? It's just a method not unlike any other. If an application doesn't cater to my needs as a developer, I won't use that application, plain and simple. I don't care how long it's been around and I don't care how many people use it... if it doesn't suit me, I won't use it. That's why I use Paint Shop Pro instead of Photoshop, for example.
|
|
|
Post by elmer on Jun 9, 2018 1:54:48 GMT
IMHO, it is probably more worthwhile to fix bugs already present in the compiler before adding new things. Just sayin'. I'm not seeing anything that was ever reported on the old thread "The new fork of HuC" on PCEFX that is still unfixed. Nor are there any open bug reports on Github. Uli says that he fixed over 70 bugs in the old HuC; and he also added a complete automated testsuite that didn't exist in it before, in order to catch regressions. I've already fixed a couple more bugs since then, and added at-least one new test. If you're suggesting that I fix some bugs in HuC, then you'll have to let me know what the bugs are, and confirm that they actually still exist in the new version of HuC. Fine, we'll skip calling it hastily-coded (even though it is) and just call it short-sightedness. Call it what you will... it's lazy implementation. PSP has supported 1-bit and 4-bit color modes since its inception. Kind of foolish that an application designed for game art can't implement this basic functionality. Also, I don't really care what others are doing... appeals to authority don't sway my opinion in regards to proper implementation of the basics. ... If an application doesn't cater to my needs as a developer, I won't use that application, plain and simple. I don't care how long it's been around and I don't care how many people use it... if it doesn't suit me, I won't use it. That's why I use Paint Shop Pro instead of Photoshop, for example. I totally agree ... you should absolutely not blindly accept any appeals to authority. But a wise man looks at the experiences of others, and evaluates whether there is anything to learn from them. If you, and your artists, are fine with your current production methods, then I would be the last person to tell you that you have to change them. But, I'm willing to spend some of my time supporting the desire of a modern professional game artist, such as Gredler, for something a little more game-art-friendly to use (for him, at least), than a generic art package like PSP. I just don't see the advantage of creating art in 16-color files. Who said it's an advantage? It's just a method not unlike any other. Oh, good. We agree, then. It's a choice. I have no intention of removing the 16-color-or-less PCX format support from PCEAS (which it internally transforms to 256-color mode for actual processing), and I'm happy to make PCEAS accept 16-color-or-less PNG format files (which it will also internally transform to 256-color mode for actual processing). I just don't see any advantage in creating art in 16-color files, when you're using a 256-color-capable editor, and when you can just voluntarily choose to restrict yourself to the first 16/8/4/2/1 colors in the 256-color palette if you wish to, and avoid PCEAS from having to do all the bit-shifting.
|
|
|
Post by gredler on Jun 10, 2018 21:17:33 GMT
OK, test time! I created a 256 color palette tile map project in ProMotion using the TurboGrafx-16 template, and generated 256 tiles using a gradient of all colors from the bottom left corner to the top right. This was then exported as .map and .pcx, and I converted the .map to .FMP using mappy, and tried to get those to load into a rom, but my ignorance coding quickly lead to failure and frustration. I then exported from ProMotion the same files as a .stm, .png, and a .pal for fun since I figured I would attach all of the files to this thread as a zip to test that functionality and to ask for a solution why my .fmp and .pcx aren't working. I figured that I would I'd include all of the files as a test bed for making progress on ironing out this workflow. Zip File contents - build.bat - batch file to run huc compiler on included .c file
- pce_tilemap_palette_tests.c - c file that I made to try and load the included .FMP and .PCX file using the current pipeline for loading tilemap art into the game.
- pce_tilemap_palette_tests.FMP - mappy exported file generated by loading included .map file and "save as" from mappy as the .FMP format
- pce_tilemap_palette_tests.map - ProMotion exported file using Tile Mapping>Export wizard dialog. This was used to generate the included .FMP file in mappy.
- pce_tilemap_palette_tests.pal ProMotion exported file using Tile Mapping>Export wizard dialog. This is not being used anywhere but was included as .PAL HuC integration has been discussed. Exported using "PAL - Plain RGB Palette" preset in wizard dialog.
- pce_tilemap_palette_tests.pce my very broken ROM generated from above included .c file, my code is wrong I think.
- pce_tilemap_palette_tests.PCX ProMotion exported file using Tile Mapping>Export wizard dialog.
- pce_tilemap_palette_tests.pmp - the ProMotion project file I used to generate all exported from ProMotion files.
- pce_tilemap_palette_tests.png ProMotion exported file using Tile Mapping>Export wizard dialog.
- pce_tilemap_palette_tests.s - generated file from HuC compile
- pce_tilemap_palette_tests.stm - ProMotion exported file using Tile Mapping>Export wizard dialog.
- pce_tilemap_palette_tests.sym - generated file from HuC compile
- pce_tilemap_palette_tests.tlc ProMotion exported file using Tile Mapping>Export wizard dialog.
- pce_tilemap_palette_tests.txt ProMotion exported file using Tile Mapping>Export wizard dialog.
|
|
|
Post by theoldman on Jun 11, 2018 8:38:03 GMT
Gredler: please look over clibref in the doc/Huc directory. Go over the functions you used; there are several errors in the way you call them.
For example, the 'new' 1 parameter version of set_tile_data() requires you use #inctile_ex(). I also don't know why you would want to call loadmap() and start at tile (16,16) on a 16x16 map.....
I personally don't use those functions. However, if you must, there was an example program floating around that showed how to use them.
|
|
|
Post by elmer on Jun 11, 2018 18:37:45 GMT
Thanks for the nice and comprehensive set of test files! Gredler: please look over clibref in the doc/Huc directory. Go over the functions you used; there are several errors in the way you call them. Thanks for your help, I really appreciate it!
|
|
|
Post by Arkhan on Jun 11, 2018 19:01:05 GMT
I'm just chiming in aside from all this color flailing to let everyone know, having used Mappy for ... 6 released projects now, Mappy is an annoying fucking dickhead to use sometimes that can lead to hours of screen-punching.
There are weird ... behaviors it has that you don't experience with Tiled. They're UI related.
Things of note that I can remember (I blocked some of it out and get PTSD when I remember):
--When you want to update your tileset because you've added new tiles or changed some, sometimes the re-importing of the tileset just doesn't work. Granted, it doesn't impact the game functionality, you're basically flying blind editing a map because the UI's tileset bank doesn't update. --It seems to see large sequences of blank tiles as "the same tile", which causes issues with importing. It's common to leave placeholder tiles that aren't done yet, but Mappy screws it all up.
You have to get creative with workarounds like blowing out literally the entire tileset and reimporting, since "ImportAt" doesn't always work like you want.
It's tedious sometimes. It's a shame since Mappy has great export/import features and other things available. It seems Tiled is just as functional, if not more functional in some regards, though.
The downside to using Tiled is you'll need to write your own BAT generation utility because you can't use the HuC #incmap stuff.
-------------------
As for 16-color, I believe Rover used 16-color because it's simpler to give people introductory things that are basic as hell. When you create a 16 color indexed image, and open it in an editor, you get to see your entire palette right there. For people who are doing programming but can't be fucked to deal with art editors/suck at art/hate art, it's a nice little bonus to see 16 big squares that clearly say "THESE ARE MY COLORS".
I used PC Paintbrush in DOSBox, and then moved to NeoPaint when Grafx2 was starting to annoy me (The Windows version at the time went wackadoo and trashed my palettes). It was easy to later tell the PCX to have more palettes if you decided you needed more. Way easier than Photoshop, who inverts everything because it's drunk.
If you need a no-frills, no-annoyance PCXable program, NeoPaint isn't a bad purchase for what you get out of it.
------------------- Also, I thought HuC *was* a student project, that used Small-Cisms as a basis, and that was what OldMan was referring to when he called something a student project. I'm not 100% sure. That was in like 1996. I was 8. It's on some mailing list archives somewhere, or buried in PCEFX.com where nobody is going to bother looking anymore because we can't. lol.
|
|
|
Post by gredler on Jun 11, 2018 20:27:40 GMT
Gredler: please look over clibref in the doc/Huc directory. Go over the functions you used; there are several errors in the way you call them. I am the worst at grasping this stuff, so I am not surprised to hear there are several error ("lots" was expected ), but it makes sense that I am using the wrong combination of functions - thanks for taking the time to look into my horrible excuse for code! For example, the 'new' 1 parameter version of set_tile_data() requires you use #inctile_ex(). I also don't know why you would want to call loadmap() and start at tile (16,16) on a 16x16 map..... So the problem is probably that I used set_tile_data() after changing #inctile_ex() to #inctile(). When that didn't work my artist-mind had me trial and error values within the functions hoping for a happy accident through blissfully ignorant keyboard mashing resulting in the 16,16 start location I converted this code over from a test map I had created that I used for testing multiple pcx constructed tilemaps, so in my oblivious changes I didn't know to change the tile data function as well. Using the correct tile data loading function instead of set_tile_data() sounds like the direction I should investigate? I personally don't use those functions. However, if you must, there was an example program floating around that showed how to use them. I definitely would not say any of this is a must, I just wanted to try to have the pcx and .fmp load as a .pce for this set of example files for any tools programmer to have access to. My hope is some generous soul will make the .png and .stm to load in the same manner as the prior file types, so I can omit the other graphics programs discussed (no psp, no gimp, no mappy) Thanks again for the feedback and thread to pull on, #inctile()'s functions for loading le tiles! Thanks for the nice and comprehensive set of test files! You're welcome, but I am hoping they are anything worthwhile to anyeone! I made them so hastefully and due to my crappy .c I was not able to even confirm the pcx and fmp are correct T_T If you need a no-frills, no-annoyance PCXable program, NeoPaint isn't a bad purchase for what you get out of it. I need the frills. I am frill seeker. I seek frills like you seek pop idols. Please relate to my desires.
|
|
|
Post by Arkhan on Jun 11, 2018 20:48:33 GMT
when I say no frills, I don't mean it's a functionless mess. It's just like, not full of all that weird stuff Photoshop has. ... that you might need, I don't know. NeoPaint is like the proper Windows equivalent of an Amiga paint program where GFX2 was never fully fleshed out. And it sees regular support. www.neosoftware.com/npw.htmlIt's only 45$, also.
|
|