|
Post by gredler on Jan 7, 2019 18:58:06 GMT
Ah thanks Spenoza, DarkKobold would know more, but I believe we're already pushing the boundaries of tile limits (I am at 214, and still have more planned to make). I think the flickering is caused by sprite-per-line, and I imagine we can design the levels around it. This level in the video DK put together as an example of all of the obstacles in a short period to try and show all the art (I think.) If we space out the obstacles a bit further apart so there are not so many on screen at once I think the flickering will go down. DK would be able to more accurately speak to this, but I don't think we can use the tilemap for the obstacles at this point. That being said, the next level we have yet to show and is in progress does use tilemaps for some of the obstacles, so maybe that was a decision he made after doing this level as a lesson learned.
|
|
|
Post by gredler on Jan 16, 2019 19:56:43 GMT
A small art update - I think we may be done with the tile maps on the vacuum level. We are currently sitting at 228 in use unique 16x16 tiles, absorbing only 11 of the palettes. I am considering making some more unique tiles and eat up some of those palettes, but have to discuss with DK if we are happy with the current state of the level or if taking advantage of the remaining budget is worth the time. I was pretty happy with my take on the classic "Dogs Playing Poker" for one of the background images. In the video it was just a picture frame with a table, but last night I finished it up and added my two dogs and the dog character from the game, Weird to see this thing look more and more like a videogame. Let's all hope the ball keeps rolling, this brings the third of five levels up to what I would consider "Beta" or content complete. There are some pixels I still want to shift around, but we have sprites and tiles in place for everything we set out to do for this level. Level design, and sound, those are different stories. Edit: I was reading over the thread and don't think I've given enough praise to elmer for getting the ProMotion NG Export system setup. When I was initially setting up this tilemap, using 11 separate palettes, we were seeing significant artifacts or completely failed/unloaded representations. This was no fault to Elmer's fine implementation, but cockpit error that I will be documenting in a tutorial on using ProMotion NG with HUC to display tilemaps. The long story short was using colors on one image from two or more palettes, obviously a failed proposition but something that required manual management in ProMotion NG. We hit many hurdles getting the final 11 palette across 228 16x16 tiles loaded from one PNG and STM, but it was entirely functional once organizing the palettes correctly (which is why Elmer probably is first hearing of these issues now.) Unfortunately although ProMotionNG has bulk/batch color correction, 16 color per tile limiting features, and color index debugging - I have not found a easy way to define in ProMotion a way to limit a tile's color range to a 16 color range instead of the full 256 range of colors; 0-15, 16-32, etc. I only see options to limit any one tile to 16 colors from any of the 256 colors, but if we were to limit any one tile to the 16 colors from any one range between the 16 palettes, it would become even easier. Perhaps there's more under the hood with the current tools. If there isn't a out of box solution then a c++ plugin could be written, and I should be able to write something like that. When I start the next tilemap for level four of five I will definitely look into trying to setup a better way to manage palettes. Having to clean up the color assignment took some extra time I could have better spent trying to make acceptable art.
|
|
|
Post by Galahad on Jan 16, 2019 22:06:02 GMT
Looking good,thanks for update.
|
|
|
Post by soop on Jan 17, 2019 14:36:59 GMT
Man, that art is looking superb!!
|
|
|
Post by spenoza on Jan 17, 2019 15:57:59 GMT
Remember, the Turbo Tunnels in Battletoads are NOT an appropriate benchmark for reasonable challenge. Go for easier than that.
|
|
|
Post by Galahad on Jan 17, 2019 16:04:10 GMT
|
|
|
Post by DarkKobold on Jan 17, 2019 17:54:16 GMT
Remember, the Turbo Tunnels in Battletoads are NOT an appropriate benchmark for reasonable challenge. Go for easier than that. Hear you loud and clear. Turbo Tunnels were too easy, will make it way more difficult.
Hell, you can be the turbo tunnel blindfolded.
|
|
|
Post by spenoza on Jan 17, 2019 21:16:50 GMT
Noooooooooo!!!!!! My plans have backfired!
|
|
|
Post by Galahad on Jan 17, 2019 22:16:07 GMT
Noooooooooo!!!!!! My plans have backfired!
|
|
|
Post by gredler on Jan 18, 2019 4:22:47 GMT
Since the beginning DK has pushed towards difficulty. I dont think I will be able to beat it, but I suck at most games I've worked on
|
|
|
Post by paranoiadragon on Jan 18, 2019 9:40:49 GMT
Looking great! One thing I was thinking(as I usually do with any homebrew) or rather, wondering, is if there's any possibility of perhaps a static bg that appears in the window to simulate "parallax" as it were. It's what I've always called a pocket o' parallax. Something like what was done in Castlevampire Z's opening level, where there's a static mountain that appears when you pass by a window.
|
|
|
Post by spenoza on Jan 18, 2019 14:52:50 GMT
Was that animated tiles or just a sprite? Probably the latter, but we'd have to ask Rover to be sure.
|
|
|
Post by gredler on Jan 18, 2019 17:31:02 GMT
Was that animated tiles or just a sprite? Probably the latter, but we'd have to ask Rover to be sure. I'm not sure if it is for the example from Yuki you're referring to, but the only way in our current setup would be animated tiles. We already have Sprite flicker from the obstacles, cat, goal, and vacuum. It might be more trouble than it's worth for DK to implement. It would not be hard for me to make a two frame animation, because that's all we have room for due to already being at 228 tiles and the tree mountains and fence are ~24 tiles. It would be very choppy, and honestly those detailed image squares move by so quickly I wonder if it would be noticeable with or without it. The speed that everything zooms by makes me regret putting a dumb amount of time into the backgrounds, but it is nice when the player is stopped to have something interesting to look at while restarting. I was hoping to have some parallax some where, but honestly there is nowhere in the game it makes a ton of sense as far as visuals. Maybe on the unshown level, but even that would be a can of worms for DK. Catastrophy will likely feature no parallax...
|
|
|
Post by spenoza on Jan 18, 2019 18:15:18 GMT
You could use parallax to warp the floor while fleeing the vacuum, and also alter the obstacle scrolling rates to mimic 3D. For example, 3 stacks of books, the foremost stack could scroll by faster than the rearmost.
|
|
|
Post by gredler on Jan 18, 2019 18:35:12 GMT
You could use parallax to warp the floor while fleeing the vacuum, and also alter the obstacle scrolling rates to mimic 3D. For example, 3 stacks of books, the foremost stack could scroll by faster than the rearmost. Yeah I did a test making the floor broken up into slices, and it actually looks kind of funky due to the shallow depth of the play field. I think parallax looks best for distant objects like a ocean or mountains or distant trees. In a shallow scene it feels much faker. As far as the obstacles they are all gameplay specific so making them move at separate speeds would make it play much differently. Parallax for the sake of parallax can sometimes make things worse. Like I said in previous post, there is opportunity but technical issues on the level we haven't shown.
|
|