FX-Unit Yuki: The Henshin Engine for TurboGrafx-16/PC Engine

[sirhcman]

[OldRover]

There is supposed to be a more complex sky but it had to be cut out of the first section due to it running way over available memory. It might fit in the tree area, but it might break consistency if added in there. No way to know for sure unless I add it in, so that is on my todo list for this week's work. Its absence is especially visible when you reach the areas with moving platforms, as seen below.

eponasoft.com/yuki-0469.png

[esteban]

The pain of cutting Cloud.

[Michirin9801]

There is supposed to be a more complex sky but it had to be cut out of the first section due to it running way over available memory. It might fit in the tree area, but it might break consistency if added in there. No way to know for sure unless I add it in, so that is on my todo list for this week's work. Its absence is especially visible when you reach the areas with moving platforms, as seen below.

eponasoft.com/yuki-0469.png

I see... Would it be a bad idea to cut down just a little bit on whatever is taking up that much memory so that you can add in detail in that sky?
I don't mean to be picky or anything, but all the other areas in the game I've seen thus far have had such luscious detail on the BGs that they're kinda sorely missed in here >w>

[OldRover]

Well, take this scene, for example...

eponasoft.com/yuki-0466.png

There is supposed to be a complex sky here. However, the number of unique tiles in this area required me to remove it to fit in the normal background details. Here, it wasn't such a big deal to remove it, as there is still plenty of detail. But these are two different areas... the volcano section and the part with the 45 degree slopes are one area, this tree section is the next area. There should be still space in the tree section to add in the sky and clouds, but even as such, it's going to require a lot of additional unique tiles to fill in said level of detail. We do what we can to make things as detailed as is feasible, but when you're dealing with a system with only one background plane and have graphics clearly intended for more than one, you have to do a lot of additional work to make things go together properly. A single variation change on something as seemingly simple as a tree branch will cost you numerous additional tiles, and that's for just one variation... the sky has numerous potential variations in it, meaning that the tile count will multiply.

[spenoza]

If you don't mind making the volcano symmetrical, couldn't you just flip the tiles for the other side? You could assign a different palette to it to still try for different shading.

[CrackTiger]

If you don't mind making the volcano symmetrical, couldn't you just flip the tiles for the other side? You could assign a different palette to it to still try for different shading.

PCE only flips sprites.

[Gredler]

Is it possible to use the same tile multiple times with different palettes? If so you could use a single tile to make the background gradient from bottom to top which would eliminate that solid color look you have now, which might satiate Michirin's concern?

[OldRover]

Is it possible to use the same tile multiple times with different palettes? If so you could use a single tile to make the background gradient from bottom to top which would eliminate that solid color look you have now, which might satiate Michirin's concern?

Not with HuC. You'd have to have your own mapper routine for that.

[Gredler]

Not with HuC. You'd have to have your own mapper routine for that.

Well darn, it'd be a lot cooler if you could! ;)

[CrackTiger]

I didn't realize that palette variants couldn't be done in HuC and had been pushing them to save on space.

I take it that fade-to-black type stuff is done using custom mapper routines?

[Gredler]

I didn't realize that palette variants couldn't be done in HuC and had been pushing them to save on space.

I take it that fade-to-black type stuff is done using custom mapper routines?

I may be speaking out of place here, but I assume it's related to multiple instances of the same tile - I think you can shift a tile's palette but all instances of that tile update at that time in the current HuC mapper code.


That's how the lights flicker on the background of level one in your game ;)

[Michirin9801]

Well, take this scene, for example...

eponasoft.com/yuki-0466.png

There is supposed to be a complex sky here. However, the number of unique tiles in this area required me to remove it to fit in the normal background details. Here, it wasn't such a big deal to remove it, as there is still plenty of detail. But these are two different areas... the volcano section and the part with the 45 degree slopes are one area, this tree section is the next area. There should be still space in the tree section to add in the sky and clouds, but even as such, it's going to require a lot of additional unique tiles to fill in said level of detail. We do what we can to make things as detailed as is feasible, but when you're dealing with a system with only one background plane and have graphics clearly intended for more than one, you have to do a lot of additional work to make things go together properly. A single variation change on something as seemingly simple as a tree branch will cost you numerous additional tiles, and that's for just one variation... the sky has numerous potential variations in it, meaning that the tile count will multiply.

I understand, but as you said, the sky detail isn't missed there because there are loads of other background details in there, but if I may suggest something:

^Like what New Adventure Island does here, just one 32 x 16 sprite of a cloud repeated here and there passing by behind the BG layer, that alone would already go a long way! It doesn't have to be that detailed, it just has to be 'something'...

But you don't have to listen to me, if you can't put anything in there then don't worry, it's fine ^^';

[OldMan]

I'm not exactly clear on what you guys are talking about, but...

Is it possible to use the same tile multiple times with different palettes?

Yes. Provided you have extra palettes to use.

You'd have to have your own mapper routine for that.

What mapper routine?

I think you can shift a tile's palette but all instances of that tile update at that time in the current HuC mapper code.

Yes, you can shift a tile's palette as well. All instances of the tile using that palette will change.
But that has nothing to do with HuC. That's how the vdc/vce operate.
....................................................................................
The BAT determines which tiles are displayed, and which palette they use.
So, for example, if you have the tile data at 0x2000 in vram, then a BAT entry of 0x1200 and a BAT entry of 0x2200 will use the same tile data, but different palettes. (The high 4 bits of the BAT entry specify the palette, the low 12 bits are the vram address / 16 )
You could then shift/change palette 2 without affecting the display of the 0x1200 entries.

I can see that there would be problems if you are loading the BAT to do scrolling and such, and it would definately be a pain to generate a background where two tiles have different palettes, but that doesn't mean it can't be done.
I think the real problem is they're running out of VRam for tile/sprite data.

[Gredler]

I think the real problem is they're running out of VRam for tile/sprite data.

Thanks for the information, and I think this is the thing Rover was talking about. I for some reason thought there could be a screen full of tiles at any given time, and the blue area was a blank tile - but could be switched to the same tile that gradates in color from the bottom row to the top.

[elmer]

Not with HuC. You'd have to have your own mapper routine for that.

You've actually managed to implement all of the lovely stuff that you guys have done within the limits of HuC's tile and map library functions??? 

Congratulations! 

A quick look at the library code suggests that that's 8x8 or 16x16 tiles (1 or 4 VDC hardware-tiles), max 256 tiles per map, max 256x256 map size, with palette defined by the tile number.

Is that right, or have I missed something?

[OldMan]

At one point, I was playing around with what you could do with tiles, just to see what was possible...

Assuming you know where the tile is in the BAT, you can read it's value via  n=vram[addr], and re-write it via vram[addr] = n. All in HuC.
So, if you mask off the upper 4 bits, then or in an adjusted palette #, it is possible.
Probably slow, but possible.
I haven't played with the HuC map functions, though. I haven't needed to. I basically set up the standard screen layout, load 2 screens to start, and then as things need to scroll fill in the new edges.

[Gredler]

As always, please excuse my ignorance but I love hearing and clarifying this stuff.

8x8 or 16x16 tiles (1 or 4 VDC hardware-tiles),

This for sure is what I've been told and stuck to

max 256 tiles per map,

Is this the conflict with vram limitations? My next question could answer this one, but is this why there could be no room in the vram for a single tile additional in the screenies of question?

max 256x256 map size,

Does that mean 4096 is the max size for a mappy (256x256 16x16 tiles)?

with palette defined by the tile number.

So to my previous question, there's not a practical/fast way to flood a screen with a single tile, then change each row's color to create a gradient for a background?

Assuming you know where the tile is in the BAT, you can read it's value via  n=vram[addr], and re-write it via vram[addr] = n. All in HuC.
So, if you mask off the upper 4 bits, then or in an adjusted palette #, it is possible.
Probably slow, but possible.

Slow in time to code, or slow in how long it takes to display each frame?

[OldMan]

max 256 tiles per map...

Is this the conflict with vram limitations?

Probably not. It's probably due using a register as an offset to load the tiles.

Does that mean 4096 is the max size for a mappy

Using the HuC functions, probably. Note that 4096 tiles works out to 8K, and I'm not sure if the map functions support crossing pages....

there's not a practical/fast way to flood a screen with a single tile, then change each row's color to create a gradient for a background?

Practical, yes. Fast, not so much, unless you go to assembler.
...
Using a temp array to hold 1 row of tile data (dependant on the BAT size), you can use
vram_read() to read in a row, then fix the tile palette, write it back (vram_load(), iirc), and bump the address as needed. Loop for however many rows you need.

Just for the record: If you do it in assembler, you can take advantage of the auto-increment
mode of the vdc, and loop using X and Y. It's actually pretty fast to do the transfer, if things are
set up right.
...

Slow in time to code, or slow in how long it takes to display each frame?

Neither. Slow in time to fill in the BAT. Assuming you don't change the BAT, its a one-shot cost.
It's slow if you have to replace BAT values for scrolling, for example. The vram[] array stuff sets the read/write address every time, which negates any advantage gained from auto-increment mode
And we know HuC is slow on array accesses (because of the address calculation it has to do)

If you're really interested in doing this, check out the vram_read() / vram_load() functions (macros?). If you can spare the space for a temp buffer, you can fill a row from vram quickly, make your changes, and then re-write it quickly. Not hard to code at all.

But much quicker in assembler....

fill_vram() { / #asm / ....asembler code here ... / #endasm / }
we do things like that quite a bit; the function is callable from HuC, and runs at assembler speed (because it is assembly)

Keep in mind, though, this is assuming you are not using the HuC map functions, and will handle scrolling / re-writing the BAT yourself.

[Michirin9801]

So to my previous question, there's not a practical/fast way to flood a screen with a single tile, then change each row's color to create a gradient for a background?

I don't know if it's possible in HuC (I assume not), but in Magical Chase on Stage 1 they actually use scanline interrupts to change the solid background colour that goes behind everything in order to do a gradient, I've seen this being done in a few other games too, such as Asuka 120% Maxima Burning Fest in the dialogue screens where they change not only the solid BG colour but at least one of the palettes as well, (see the dialogue box near the bottom of the screen) and on Metamor Jupiter on that rotating tube background...
So yeah, you don't even need tiles to make a gradient in the sky, and if you did it that way the gradient wouldn't move together with the BG if it moved vertically, thus making a bit of parallax, but again, I don't know if HuC supports that...

[elmer]

Assuming you know where the tile is in the BAT, you can read it's value via  n=vram[addr], and re-write it via vram[addr] = n. All in HuC.

It's a cool programming-metaphor, but it's actually (slightly) slower than the dedicated __fastcall functions that do the same thing, so FYI, I removed those vram[] arrays in the new HuC.

But much quicker in assembler....

fill_vram() { / #asm / ....asembler code here ... / #endasm / }
we do things like that quite a bit; the function is callable from HuC, and runs at assembler speed (because it is assembly)

Keep in mind, though, this is assuming you are not using the HuC map functions, and will handle scrolling / re-writing the BAT yourself.

Yep ... HuC is OK, as long as you're using the built-in library functions (written in assembly-language)  to do stuff ... but anything that it doesn't directly support is only going to run fast if you write your own optimized assembly language code for it.

Arkhan and TheOldMan have spent a long time learning just what does, and does not, need that kind of optimization in their games. 

As always, please excuse my ignorance but I love hearing and clarifying this stuff.

There's never anything wrong with asking questions! 

max 256 tiles per map,

Is this the conflict with vram limitations? My next question could answer this one, but is this why there could be no room in the vram for a single tile additional in the screenies of question?

It's because the map in HuC uses a byte to store the tile number, rather than a 16-bit word/int.

That halves the amount of space needed for the map ... but it means that you're limited to 256 tiles.

And there's no room in the map to store a palette number either, so the palette number to use is looked-up from the tile number, instead of just being a part of the map-data.

It's a design trade-off ... reducing the size of stuff in RAM/HuCard, but causing a limitation in the graphics.

Consider ... 256 16x16 tiles take up 32KB of VRAM ... that probably seemed like a sensible limit when HuC was written.

OTOH ... 256 8x8 tiles only take up 8KB of VRAM, and severely limits the graphic-quality.

Design trade-offs are like that ... there's no one-size-fits-all solution! 

max 256x256 map size,

Does that mean 4096 is the max size for a mappy (256x256 16x16 tiles)?

As-in 4096x4096 pixels maximum map size? Well yep ... kind-of.

Except that HuC also has a secondary mechanism for using multiple 256-tile-x-256-tile maps within a 16384-tile-x-16384-tile area.

But that's getting really complicated, and I suspect that you'd be better-off writing your own map functions if you needed large maps like that.


The low-RAM (i.e. HuCard) 4th-gen stuff that I've done used the tile/block/map design.

There the map is still byte-per-entry, but the byte is a block number (0..255).

Each block is then a 4-word 2x2 tile entry, allowing up to 1024 tiles, and allowing each tile in each block to specify its own palette.

Still limited ... but it allows for the reuse of tiles with different palettes, and it allows for more tiles (i.e. better graphics).

But again, it has its own design trade-offs.

BTW ... if you get sneaky, you can use certain map codes to trigger the loading/swapping of the block definitions to work around the 256-block limit. 


When you have more RAM, like on the PCE CD, you can use 16-bits per entry in the map, with up to 4096 tiles, and full palette usage ... and then sectorize and compress everything and just decompress the sectors that are close to the player.

That gives you the greatest flexibility ... but it comes at the cost of complex art-tools and runtime code.

with palette defined by the tile number.

So to my previous question, there's not a practical/fast way to flood a screen with a single tile, then change each row's color to create a gradient for a background?

I can't think of a *simple* way, within the design of the HuC library, particularly if you're scrolling the screen.

If you drop down into ASM, you could do a nasty hack ... but if you're writing in ASM, then you'd just redesign the map functions and avoid the limit altogether.

So yeah, you don't even need tiles to make a gradient in the sky, and if you did it that way the gradient wouldn't move together with the BG if it moved vertically, thus making a bit of parallax, but again, I don't know if HuC supports that...

Good point! 

That might be the sane way to do something with little cost, but it might need custom assembly-language code and, if so, could easily cause lots of problems with HuC's existing split-screen hblank-interrupt code.

IMHO, it would be a risky thing to try to add to Henshin Engine at this point.

[Gredler]

Thanks so much for the break down Elmer and Old Man, your concise and clear explanations register somewhat.  I appreciate you guys taking the time to elaborate; even if some of the specifics are Greek to me I think I understand the ideas.

Even with solid color bg's the art shines through and Henshaw continues to look great, keep up the good work fellers!

[OldRover]

So whilst swimming about, Yuki gets the point.

eponasoft.com/yuki-0471.png

And yeah elmer, the visuals have all been done within the limits of stock HuC 3.21 thus far.

TheOldMan, as far as I know, HuC's tile mapper thingo assigns each tile to a specific palette when you load everything in, and there's no direct way to monkey with it without haxoring the mapper code, which is beyond my meager code orangutan skills.

EDIT: Interesting observation as soon as I posted that pic... I forgot to fill in the appropriate edge tiles along the barrier. Dangit.

[Michirin9801]

So whilst swimming about, Yuki gets the point.

eponasoft.com/yuki-0471.png

Looks pretty good ^^
_{(Please tell me those tiles are dynamic)}

So yeah, you don't even need tiles to make a gradient in the sky, and if you did it that way the gradient wouldn't move together with the BG if it moved vertically, thus making a bit of parallax, but again, I don't know if HuC supports that...

Good point! 

That might be the sane way to do something with little cost, but it might need custom assembly-language code and, if so, could easily cause lots of problems with HuC's existing split-screen hblank-interrupt code.

IMHO, it would be a risky thing to try to add to Henshin Engine at this point.

I'm not saying they should do it in Henshin Engine but...
I wonder if it's possible for a future version of HuC to support this feature ;3

[Arkhan Asylum]

You can use the same tile with a different palette if you do it ahead of time.

See: Atlantean.

Same tile, different (darker) palette was used for the back row of buildings.   Once it's loaded however, you're sort of fucked with the built ins, IIRC.  Or there was a way to do it but it was sort of goony.     

I honestly haven't touched much PCE stuff in a few years because of MSX, outside of noodling with music, and talking to old man about random stupid ideas and how-tos.

I don't want to 6502 my brain in the middle of z80ing a game.   lol

[spenoza]

Well, hurry and wrap that up so we can get you back over here in 6502-land!

[NecroPhile]

Well, hurry and wrap that up so we can get you back over here in 6502-land!

He's got two months to finish up Saber Rider.  That's plenty of time. 

[Arkhan Asylum]

Well, hurry and wrap that up so we can get you back over here in 6502-land!

It's basically done.  we're just finalizing production stuff at this point.

[OldRover]

There is probably a way to mess with the combined map+palette data, but I don't know how to do that. If that could be done, then it would help out a lot, but I dunno how to do it. What would help more than just the basic map import stuff is to have an option to import a file that contains both the tile index and the palette index at once rather than having to #incbin a map and #inctile/#inctile_ex the tileset... just have one single #incmyawesomemapfileyo or waddat that contains both the palette index and the tile index, so that way the same tile in VRAM could be used with multiple palettes. But alas, no such fun stuff. *sadface* That would have helped a lot for stage 3's parallax... it's loading the same data multiple times. It doesn't hurt the efficiency at all but it just seems redundant and could be done a lot cleaner if HuC allowed ya to do said things natively without goony hacks.

[OldRover]

This is not a screenshot but a fragment of the map of 4-2. Some tiles were redesigned so more background detail could be added.

eponasoft.com/badonkredesign.png

It still plays the same as before, it just looks a bit different. No more big empty spaces.

[ParanoiaDragon]

Cool, reminds me of Super Air Zonk with the lil wavey's in the skyline.

[Michirin9801]

This is not a screenshot but a fragment of the map of 4-2. Some tiles were redesigned so more background detail could be added.

badonkredesign.png

It still plays the same as before, it just looks a bit different. No more big empty spaces.

♥~YAAAAAAYYYYY~♥

[esteban]

Magnifique.

[sirhcman]

This is not a screenshot but a fragment of the map of 4-2. Some tiles were redesigned so more background detail could be added.

badonkredesign.png

It still plays the same as before, it just looks a bit different. No more big empty spaces.

Looks like this was copied straight from Catastrophy! ;)

[elmer]

This is not a screenshot but a fragment of the map of 4-2. Some tiles were redesigned so more background detail could be added.
...
It still plays the same as before, it just looks a bit different. No more big empty spaces.

That looks so much better! Excellent work! 

What would help more than just the basic map import stuff is to have an option to import a file that contains both the tile index and the palette index at once rather than having to #incbin a map and #inctile/#inctile_ex the tileset... just have one single #incmyawesomemapfileyo or waddat that contains both the palette index and the tile index, so that way the same tile in VRAM could be used with multiple palettes. But alas, no such fun stuff. *sadface*

You can already do stuff like that just by creating/using a separate conversion step, and some custom assembly-language code, and just #incbin the resulting data.

I could be wrong, but I thought that Arkhan was already doing that in his projects.

HuC itself can also be improved, there's nothing magical about it ... but people have to actually be willing to push-the-envelope and use new tools in order for it to be worth some third-party spending their time to make improvements.

Now is absolutely the wrong time to do that for Henshin Engine, you guys are far-too-far along.

But when/if you start the next project ... that's something for you all to think about.

[Gredler]

Looks like this was copied straight from Catastrophy! ;)

You must be privy to some screenshots I've not seen,  because that looks gorgeous and much further along than any Catastrophy stuff; a massive improvement from previous iterations - great job henshin team!

[CrackTiger]

Looks like this was copied straight from Catastrophy! ;)

You must be privy to some screenshots I've not seen,  because that looks gorgeous and much further along than any Catastrophy stuff; a massive improvement from previous iterations - great job henshin team!

That section on its own with a 4 - 6 screen view looks like one of those cat platform towers.

[OldRover]

The final public demo of the game will be on display this weekend at the Lvl Up Expo in Las Vegas, NV. I won't be attending this year, but Sarumaru will be there. The release of the finished game is just a few months away. The finished game will be available for play at the Game On Expo in Phoenix, AZ in August. I will be there.

[shubibiman]

 

[esteban]

The final public demo of the game will be on display this weekend at the Lvl Up Expo in Las Vegas, NV. I won't be attending this year, but Sarumaru will be there. The release of the finished game is just a few months away. The finished game will be available for play at the Game On Expo in Phoenix, AZ in August. I will be there.

Maravilloso.

[OldRover]

eponasoft.com/yuki-0481.png

Can't see it on this screenshot, but the water is now animated... so it really looks like Yuki is underwater.

[CrackTiger]

If it's using the tiles I made for the effect, it looks like this:




But the timing may be different, as everything I look at gifs with runs them at slightly different speeds.

[esteban]

Goddamn, this is gorgeous.

[OldRover]

The timing looks pretty similar here. In-game, the animation runs at 7.5fps, or every 8 vsyncs.

[Michirin9801]

Looks nice but... Umm... Those are animated tiles right? I think they could look a bit better...
Uhh, are these tiles final? Would you mind if I gave it a shot at making a better animation within the same amount of frames? I'll do it for free, I'm not asking for anything!

Here's a couple of examples of my pixel art for the Mega Drive:



For the GBC:


And one with only 16 colours:
16_color_sunset_by_michiharuruko-d8ixh2q.png

[OldRover]

Nice pixels!

The above animation was a mockup and is not exactly what is in the actual game... the frame sequence is different and looks nicer in-game.

[Michirin9801]

Nice pixels!

The above animation was a mockup and is not exactly what is in the actual game... the frame sequence is different and looks nicer in-game.

Thanks ^^

Ooh I see... _{*sighofrelief*}
That's good to know, I'll be looking forward to seeing it in action ;3

[OldRover]

/yuki-0500.png

Geni went too far this time. Now it's on 4realz.

[Michirin9801]

Looks very nice ^^
Does it parallax though? ;3

[ParanoiaDragon]

Looks very nice ^^
Does it parallax though? ;3

Ha, I think you have the same obsession I have with paralax!

So Nod, will she be tinted blue while in the water?  Also, on another note, can't wait to hear the Badonk tunes, I'm curious to see how much they might resemble my own Bonk tunes I did.  So far, there's a halfway retro sound in the tunes, & that's what I did as well.  I expect an eargasm from Badonk's Misadventures!