|
Post by elmer on Jun 27, 2018 18:46:49 GMT
The blank tile problem. I will agree that we disagree if this is a problem or not, but there are reasons for removing that blank tile. Sure, sometimes a project's graphics get to the complexity that the team really can't afford to allocate the space for a blank tile that they are not actually using in their graphics. But ... until they actually get to that point, there's a pretty damned good likelihood that they do have some blank area in their map, and that they are using the blank tile, and that they can afford the VRAM space for it, and so they can just use the existing ProMotion export, with its blank tile 0, without any problems at all. When they do finally hit that limitation, there are far, far easier ways to work around the situation than the fragile multi-project Rube Golberg scheme that you propose, which, as you point out yourself, still ends up with the map indices themselves broken and off-by-one. You could have achieved exactly the same end-result just by exporting the tileset from the Map project as a single long image, with its blank tile, the way that ProMotion normally does it, and then writing a #incile command in HuC that just skips loading the first tile in the tileset image. #inctile "tileset.png",16*1,0,255,1 That would still end up with the off-by-one map, but it would avoid all of the pointless messing around with multiple ProMotion projects. You could even "fix" the map, just by telling HuC that the tileset started in VRAM one tile earlier than where you actually load the tiles ... but that would limit you to 255 tiles. If a HuC-based project (such as FX Yuki) were to use ProMotion, but they really needed to use all 256 tiles in HuC, without having a blank tile, then there are other simple ways to accomplish that. 1) If their graphics are that complex, then they're probably also using animated tiles. They could just use tile #0 as one of their animated tiles, and not worry about it being blank in the ProMotion tileset. or 2) They could just use tile #256 to define any graphics that would go into tile #0. Any uses of tile #256 in ProMotion's 16-bit-per-tile STM map will automatically become references to tile #0 when the map is converted into HuC's 8-bit-per-tile map. Then they would just include ProMotion's tileset in HuC in 2 parts ... #inctile "tileset.png",16*256,0,1,1 #inctile "tileset.png",16*1,0,255,1
... and everything would work. Those are just some of the simple options for working with ProMotion's export and still using the simple map system that is built into HuC. Developers get more and better options once they progress passed the point of using that HuC system, and start to use external tools to process the map data, and use their own code on the PCE to display it. We can certainly talk about that advanced stuff here, but I think that we should move that chat to another thread, and leave this thread to focus on HuC users. A workaround for the tilemap export would be to use the export as individual image files per palette then loading each in (or combine them using a script or other art program) That's not necessary ... see above. Wow, this is such a mess because of one dammed tile. Nope, it's such a mess because theoldman is dramatically over-complicating things so that he can avoid changing his honest and deeply-held belief of how things should work. Which is especially frustrating to me since Aetherbyte are apparently already using an external conversion program in their toolset, and so they would only need to do a few hours of work to build far better conversion capabilities into it than we are talking about here.
|
|
|
Post by spenoza on Jun 27, 2018 20:36:11 GMT
I think developers can have differing views about what is and isn't an effective process or toolchain or priority for asset organization. Aetherbyte has demonstrated pretty good code competence so far in that they've released stuff and it works. For the purposes of THIS discussion, let's just stick to providing Gredler and DK some options and letting them determine what their workflow preferences are. I'd like us not to go making value judgments about others based on their possible workflow or coding preferences, especially when they have proven they can deliver.
|
|
|
Post by theoldman on Jun 27, 2018 20:42:26 GMT
"Sure, sometimes a project's graphics get to the complexity that the team really can't afford to allocate the space for a blank tile.... But ... until they actually get to that point, there's a pretty damned good likelihood that they do have some blank area in their map..." No. Look at just about any side-scroller. Remember, that 'blank' tile is going to display as all black. "there are far, far easier ways to work around the situation than the fragile multi-project Rube Golberg scheme" Agreed. But the first step in finding those solutions is knowing it can be done. I'm not advocating doing it this way. I'm just explaining that it can be done, and here's one way to do it. Why do you think I said it wouldn't be pretty? "You could have achieved exactly the same end-result just by exporting the tileset from the Map project as a single long image" I actually should have thought of this. How wide of an image will HuC let you include? "You could even "fix" the map, just by telling HuC that the tileset started in VRAM one tile earlier than where you actually load the tiles ... " This I'm not so sure about. Got an example of how to do it? "Developers get more and better options once they progress passed the point of using that HuC system, and start to use external tools to process the map data...." I'm well aware of that. But you have to start somewhere. "Nope, it's such a mess because theoldman is dramatically over-complicating things so that he can avoid changing his honest and deeply-held belief of how things should work." Nope. It's such a mess because I took a model that was known to work, and replicated the method. Just to prove it -could- be done. I have no belief that it should be done this way. I moved away from that method years ago. "Which is especially frustrating to me since Aetherbyte are apparently already using an external conversion program in their toolset..." Yes. But not everyone has / wants to develope their own tools. Somebody coming to this new will want a way to do this. And then quickly abandon it "... and so they would only need to do a few hours of work to build far better conversion capabilities into it than we are talking about here." What makes you think we haven't? This whole conversation has led to the development of: A PNG to PCX converter. (For those who want PNG graphics and the 'old' HuC A STM to FMP converter. (Again, for those who want ProMotion maps in the 'old' HuC. And it will soon have a switch to handle that -1 problem) A palette extraction utility. It creates that annoying palette array in a #include -able form. And checks for problems. And a util that strips that annoying blank tile from pcx files. ......................................................................................................... So, the wok flow goes like this: Create everything in ProMotion. Save the tiles in a PNG, and the map in an STM. Run the png through the converter (everthing else uses PCX files; they are easier to deal with) to get a PCX file. Strip the blank tile from the PCX (no need for it) Run the palette extractor on the PCX to get a text file to #include. Run the STM through the FMP converter, to get an FMP. Now you can include the PCX tiles, the FMP map, and the palette array file. Works great with make, where you can specify the dependancies and do it automatically. Just 'make graphics' The next step is to take some of the routines developed and port them into our 'main' utility. It generates a BAT file; I really want to give it the option of building the palettes from the graphics file, rather than having to specify which tiles are in which palette, like it does now. Then you can #incbin() the bat file, and either vram_load() it, or load parts of it via custom routines. I WANT A BLOODY LONG LEVEL IN MY PLATFORMER, OKAY? (Don't judge me)
|
|
|
Post by gredler on Jun 27, 2018 22:24:31 GMT
A palette extraction utility. It creates that annoying palette array in a #include -able form. And checks for problems. And a util that strips that annoying blank tile from pcx files. Is that going to be a publicly available tool?
|
|
|
Post by elmer on Jun 28, 2018 3:02:39 GMT
I think developers can have differing views about what is and isn't an effective process or toolchain or priority for asset organization. Errrrr ... yep. What else do you think it is that we argue about when we're all in the pub, getting sh*tfaced together? I'd like us not to go making value judgments about others based on their possible workflow or coding preferences, especially when they have proven they can deliver. If you honestly thought that that was what I was doing, then I apologize to theoldman. I tried to be careful to walk the line of disagreeing with the message itself, without disparaging the messenger. You really wouldn't like the Linux Kernel Mailing List. No. Look at just about any side-scroller. Remember, that 'blank' tile is going to display as all black. Sure ... but having that blank tile there doesn't actually make any practical difference to your artwork unless you are using all 256 of the tiles that HuC allows, and, for some reason, you don't want to just use tile #256 in ProMotion, and have it wrap around, as I suggested. OTOH, if a team does use a blank tile in their map, and you go and quietly remove it in a your conversion tool and silently renumber the map ... then you've created a graphical corruption on the screen that's going to take someone on that team a great deal of time and effort to diagnose and debug. I prefer to follow the KISS principal, and go for WYSIWYG as much as possible. It is (IMHO) easy for the team to work with tile #256, once they get to the point of needing to. How wide of an image will HuC let you include? I'm afraid that the HuC has been limited to 1024x768 images for gawd knows how many years now. There is no technical reason for that in the code ... I can only guess that it came from an old DOS version of HuC that was probably tied to the capabilities of an IBM VGA graphics board. Whatever the history was behind the reasoning, I've changed it today so that it will read up to 16384x4096 PCX and PNG images. Changes are only needed to a couple of lines of code, if you would like to apply them to the old HuC source and rebuild it. The changes are checked-in to github, if you wish to browse them. So ... Nope, the classic version of HuC won't allow developers to use the #inctile tricks that I mentioned, and they would have to use your external programs to modify ProMotion's output to remove the 1st tile ... if they decided that really needed to do that. Those external programs won't be needed with the next build of the new HuC ... but they could still be used, if you make them publicly available, and if the development team wishes to do so. Flexibility is good! "You could even "fix" the map, just by telling HuC that the tileset started in VRAM one tile earlier than where you actually load the tiles ... " This I'm not so sure about. Got an example of how to do it? It's been a long day, and I'm tired ... but I'll try to write up an example of that tomorrow. "Which is especially frustrating to me since Aetherbyte are apparently already using an external conversion program in their toolset..." Yes. But not everyone has / wants to develop their own tools. Somebody coming to this new will want a way to do this. And then quickly abandon it Absolutely! Most folks don't or won't write their own tools, despite the additional power and capability that that gives them. Which is why I'm trying to improve the ability of new-ish developers, like Gredler and DK, to accomplish what they need with the basic HuC toolset, and do so without too many hidden traps to fall over. Experienced developers, such as you guys at Aetherbyte, already have your own work-arounds in place to fill in the gaps that the old classic version of HuC suffers from.
|
|
|
Post by theoldman on Jun 28, 2018 4:20:19 GMT
"Is that going to be a publicly available tool?"
Which one? The palette index generator, probably. Its a sorta useful but throw-away tools (There are lots of other ways to do it).
The Others? That's kinda iffy. Arkhan sees these things as a 'competative edge', so he's reluctant to release them. Which is not really a big thing. They go out of date quickly, as we change them to fit the current project.
One thing everyone needs to be aware of is there won't be any source code included. We share a lot of code between utils, and it cost time to build some of those libraries. If you can write a game, you can write your own libraries/utils. You don't need ours. Heck, maybe they will even be better .................................................................. " until they actually get to that point, there's a pretty damned good likelihood that they do have some blank area in their map, and that they are using the blank tile, and that they can afford the VRAM space for it, and so they can just use the existing ProMotion export, with its blank tile 0, without any problems at all. "
So, If I understand this right, it's okay to do this until there's actually a problem, and hope it won't happen.
At which point, you have to figure out a way around it?
Crunch time is bad enough as it is without having to re-do things. We will agree to disagree on this one.
"I'm afraid that the HuC has been limited to 1024x768 images for gawd knows how many years now." Got it. So if I use one long strip, I can only have 128 8x8 pixels tiles. Sounds like a good reason not to use a long strip for tiles.
" I've changed it today so that it will read up to 16384x4096 " God, that has to suck up RAM. I guess it's okay now, but I would hate to try it on a machine with < 1 G Ram. Of which I have a few. Though that's one way of getting a longer image strip, I guess.
"So ... Nope, the classic version of HuC won't allow developers to use the #inctile tricks that I mentioned, and they would have to use your external programs to modify ProMotion's output to remove the 1st tile ... if they decided that really needed to do that."
Well Arkhan said he's looking for a mappy replacement. We would definately need external programs, as we need to feed the data through several utils to get it the way we want. No matter which version of HuC we use.
I'm thinking of a 256 tile wide level which transitions from grass-land to desert. I think it might take more than 256 tiles to do that. Especially since I plan on loading the sprite animations on-the-fly.
|
|
|
Post by Arkhan on Jun 28, 2018 4:45:44 GMT
The Others? That's kinda iffy. Arkhan sees these things as a 'competative edge', so he's reluctant to release them. Which is not really a big thing. They go out of date quickly, as we change them to fit the current project. ...No I don't. Don't make shit up and make me look bad in the middle of an already borderline retarded argument. There are already, or were already (somewhere) similarish utilities from Tom floating around. I'm really not sure what you're talking about. After using Mappy for Inferno, I decided I will never use that piece of shit again. Except for that time I used it for Nantettatte Engine because I just had to do a few diddly things to replace Reflectron's crap with NTTE's crap. I've only half-heartedly been following this thread because I don't use ProMotion. I have used Mappy enough to know it doesn't play nice. EDIT: And when we sort out what replacement we are using, it will likely be for an MSX project, but the general concepts and utilities would translate to PCE sort-of-easily. I'm not doing much in the way of game programming at the moment because I am gluing Infernos together and enjoying not making a game at the moment. EDIT 2: And FWIW,I think I told Gredler more or less what Elmer said to do, but it was in chat and probably a bit scrambled since we were actively fucking off in the chat at the same time, lol. We don't use HuC's #inc crap for the tiles/bats and haven't for a long time, so the utility being used wouldn't benefit Gredler unless he wants to use asm calls to load data...
|
|
|
Post by theoldman on Jun 28, 2018 6:05:36 GMT
" "The Others? That's kinda iffy. Arkhan sees these things as a 'competative edge', so he's reluctant to release them. Which is not really a big thing. They go out of date quickly, as we change them to fit the current project. " ...No I don't. Don't make shit up and make me look bad in the middle of an already borderline retarded argument. "
Dude, relax. I'm not trying to make you look bad. It's a business decision about whether things get released (ie, go public) or not. People understand that. You don't see Micro$oft releasing the windows code. Or Sony releasing their stuff. Some things are public, and some are private. That's all I was saying.
"There are already, or were already (somewhere) similarish utilities from Tom floating around. I'm really not sure what you're talking about."
Yes. They are on Toms blog. So nobody really needs ours. I'm cool with that. I can also understand not releasing our versions.
First, I'd be ashamed of how the source looks.
Second, there really is a lot of 'librayish' code I use again and again. Especially for dealing with FMP files.
Finally, there really are things nobody else needs to have.
Or do you really -want- to release the utils we used to build HuCards, so all those people making cards can start producing copies of free hoewbrew stuff? Granted, they can do that anyway. They can even make jp/us versions like we did. (though that doesn't matter much now in the age of mods). But do you want to put out a tool-chain to automate that? I don't.
There are tools you have told me to keep to ourselves. The map->bat program. The various gfx converters. Things that let us transform files into binary data that can be used in a load_vram() call, rather than having to go through the sometimes obnoxious HuC routines.
I still remember how you flipped when I gave Rover the cue sheet generator. And that was just one small part of the tools I built for doing cds. (It was Rover that did that magazine game, right? If not, substitute the right name in there).
So, from a business and a personal view, it makes sense to run these decisions by you. And to stand by your decision. It's not making you look bad anymore than the Sony CEO saying he's dropping Linux support from the PS3. People may not like it, but that's their problem. From a business view, it makes sense. And they can live with it. ...............................................................................................................................
"I've only half-heartedly been following this thread because I don't use ProMotion. I have used Mappy enough to know it doesn't play nice. "
I wasn't impressed with ProMotion in the time I tookto play with it. It looks like it has some nice bells-and-whistles, but I had a hard time doing even basic map editing. Drawing on the active map and creating tiles is sorta nice, until you screw up and go outside the tile and end up with extras. I had a real hard time with that; once I went to delete the extras, it took a lot of poking to figure out how to get back into draw mode. It would probably be fine, if I were doing a game with multiple graphics planes and tons of sprite animations, but its really over-kill for the stuff the PCE does. It might grow on me though, if I used it more.
So what was the one you mentioned? Tiled? I'm sure we could come up with something to read those maps (if somebody hasn't already), and from there it's not hard to go to an fmp file for HuC. Just throwing the idea out there.
|
|
|
Post by Arkhan on Jun 28, 2018 6:38:04 GMT
Dude, relax. I'm not trying to make you look bad. It's a business decision about whether things get released (ie, go public)or not. People understand that. You don't see Micro$oft releasing the windows code. Or Sony releasing their stuff.Some things are public, and some are private. That's all I was saying. I never said anything about a competitive edge, though. There were some tongue in cheek comments about the SFX for MML, but nobody uses MML so there's no real competitive edge. We're still the only people running that three legged race, lol. ... There isn't much tooling involved in anyone making HuCards. They're already easily cranking out those things. Homebrew, commercial releases. If you think they're jumping through crazy hoops, they aren't. This wasn't for any sort of competitive edge. This was more because they (at the time) were clunky, sort of specific to what we were doing, and it wasn't worth the hassle of upping them and trying to explain/support them to people when they ask. What? These aren't really business decisions. Its more like "do not feel like dealing with this" decisions. Some people like making games, other people just like making tools/utilities. I don't not share utilities for some hoarding purpose. I am OK with giving people things that might make their lives easier, but what we have is a bunch of stuff that anyone who's doing the required(ish) assembly code can/has done themselves. It's not HuC friendly stuff because none of it was really made with the intent of giving away. Some people give tools like that away, and it confuses users of it lol. Squirrel was for people, and I took the time to make sure there was a big instruction manual, sample songs, and that the thing itself was usable. .... and look how that went. lol I already started writing something for Tiled / MSX, started planning how to do it for PCE, but then stopped because I'm taking a break. I will finish writing that when I feel like it, but I won't be surprised when one of you decides in the meantime to up and do it yourself now that it's been mentioned. It's a CSV inside an XML block. It's not really rocket science. It's like a less convoluted Mappy file. The program itself is just less of a goddamn nightmare compared to Mappy. You might as well just write a Promotion utility instead of that's what artists are using. Tiled is just a Tile editor. For Gredler's purposes, it seems like having 100% ProMotion support with no need for Mappy ever in his life would be his favorite thing.
|
|
|
Post by gredler on Jun 28, 2018 8:20:05 GMT
I was specifically talking about the tools for generating palettes per tile as an include, that sounds rad.
|
|
|
Post by Arkhan on Jun 28, 2018 8:30:14 GMT
I was specifically talking about the tools for generating palettes per tile as an include, that sounds rad. I swear there were already similar tools out there, but some of them seem to be missing / MIA now
|
|
|
Post by spenoza on Jun 28, 2018 13:21:50 GMT
Go to Tom's blog and poke him via email or something. He might still have some tools around.
Elmer, yeah, I think the Linux community is pretty toxic in many ways. I think people can disagree, vehemently even, without being dicks. Linus sets the tone in that community and he clearly disagrees with me on that. I just don't want to see disagreement turn into bad feelings or toxicity in our small dev community. It's already clear that people are 1) sharing ideas and 2) doing things their own way, and those are clearly compatible and work just fine.
|
|
|
Post by Arkhan on Jun 28, 2018 16:22:34 GMT
Everything is toxic. That's why we all die.
|
|
|
Post by gredler on Jun 28, 2018 18:25:57 GMT
I don't know what tools we would need until a challenge arises to require it. It is too early for us to asking for any tool in our project's current state beyond supporting a file type that ProMotion can export for tilemap placement (which is already implemented. I don't want to put the buggy before the horse because we have everything we need for now, and when the problems arise maybe DK will make tools, or I (hahahaahahahahah) will try to make a tool or two as well. I definitely want to make some tools, and should be able to do some basic bitch shit at least.
I do really appreciate the generosity and community support, we are a small group who can get snippy with eachother, but I feel like there's a lot of love and encouragement here and that positivity is very awesome!
|
|
|
Post by Arkhan on Jun 28, 2018 19:19:42 GMT
I think realistically, the main thing needed is something besides Mappy support.
That thing is like PTSD Vietnam shit at this point.
If there is an interim workaround though, just use that.
That's ultimately what everyone ends up doing.
Mappy is too buggy/wonky to continue using. Leave the .FMP support in there but expand HuC to understand Promotion, if that is the route being used.
|
|