pseudo hires stuff

[d4s]

im currently working on an enhanced version of breath of fire 2 and did some investigations (of the trial and error kind ;) regarding the pseudo 512 pixels hires mode on the snes.

apart from translating the game im trying to visually enhance it.for example, i implemented textboxes resembling those of star ocean. (a horizontal gradient turning from translucent to nearly-opaque using hdma cgadsub)

to further improve that, i wanted to switch to pseudo hires mode to fade the textboxes background against the text because i remember this mode looking super-sexy on a real snes when displayed on a rgb-monitor.(sort of like vertical scanlines)

to make a long story short:
it works fine on a real snes, but fails to display in both zsnes and snes9x.
i knew that zsnes doesnt handle pseudo hires properly anyway, but i assumed snes9x did.
there is a map in the original bof2 game that uses pseudo hires and it displays fine in both zsnes and snes9x, that seemed weird to me.

im not asking to fix it or anything, just wanted to point it out and offer my help if additional tests are needed.

however, i ended up not using pseudo hires, because
1.) it looks jaggy and colors get distorted when using composite video
2.) a similar graphical effect could be achieved by setting color addition to 1/2. (d'oh!)

here are two pics of that effect using composite video for those who are curious:

pseudo hires enabled on textbox only:
http://www.geocities.com/pottnuttenschu ... udo512.jpg

pseudo hires disabled:
http://www.geocities.com/pottnuttenschu ... gadsub.jpg

imho, the pseudo hires mode would look better when rendered 512 pixels wide, not 256 with sub and mainscreen pixels blended together, like snes9x/zsnes seem to currently do.

[Nightcrawler]

You're bandwith has been exceeded for today so I can't see your screenshots.

It's rare that code fails on ZSNES and not on the SNES, it's usually the other way around.

When/if you figure out what's going on here, it may be a good idea to post your findings in the dev forum so the emulators can be fixed. If you give me a more detailed summary about what you're doing in your code and where you're doing it, I may be able to give you some hints as to where the problem might be. I'm fairly famaliar with several SNES vs. emulator issues.

[d4s]

You're bandwith has been exceeded for today so I can't see your screenshots.

It's rare that code fails on ZSNES and not on the SNES, it's usually the other way around.
When/if you figure out what's going on here, it may be a good idea to post your findings in the dev forum so the emulators can be fixed. If you give me a more detailed summary about what you're doing in your code and where you're doing it, I may be able to give you some hints as to where the problem might be. I'm fairly famaliar with several SNES vs. emulator issues.

im using 2 hdma channels.

first one:
4 regs write once, starting at $2131:cgadsub, coldata, setini and multiplication result low(last one isnt used. i dont know if theres a way to write 3 registers once, but it doesnt matter cause its write-only, anyway afaik).
i set bit 3 only of setini when the textbox starts.


second one:
2 regs write once, starting at $212c (main and subscreen designation).
during the textbox, i have all layers enabled on the mainscreen(bg1-4, sprites).
the subscreen has bg3 enabled, only.(the text is on bg3).
from what i can tell, this should display all layers on the even pixels and only bg3+backdrop colour on the odd, and it displays just like that on the real machine.(its hard to tell on the screenshot cause the composite video causes some jittering)
on emulators, all layers appear on both even and odd pixels.

the remaining screen space of all 5 affected registers is always set to what the game demands, in order to avoid fucking up the games graphics when its using translucent layers.

btw, i only enable hdma channels at the very end of the vblank routine, in case you assumed i was a total dumbass when it comes to emu/real hardware issues.
i dont write to vram outside vblank, either.
as i said, its working like a charm on the real thing.

i dont know very much about the snes graphical capabilities compared to guys like anomie or byuu(just have been going through various docs and picked up some details here and there in the sne9x and zsnes forums), thats why im not sure if i can reliably pursue whats going on.
i just wanted to point this out in case somebody believed the pseudo hires stuff is working 100% in emus.

[Nightcrawler]

Ok.. It sounds right to me. This is a bit out of my area of expertise though. I haven't really messed around with the hi-res mode.

Obviously since it works on the SNES, you're doing something right. I would say emulators are not handling this resolution 100% correctly.

I would also question implementation of HDMA. I think there are still bugs present here as well, although I couldn't tell you what they are.

Sorry that I'm pretty much useless in helping to figure out what's going on with this problem.

Try Super Slueth and see if it displays properly. Super Slueth is a newer SNES emulator focusing on accuracy. I'm curious if this emulator will work correctly with this.

Anomie was supposed to be working on 'perfect' graphics handling code for SNES9x if I remember right. I wonder what he would have to say about this.

[byuu]

I'm sorry, but pseudo-512 mode is the only feature I have not emulated for the PPU. I do know how it works, but without actually implementing it myself, I don't feel comfortable giving advice on it. Hopefully anomie can help you out here. It sounds like you've found an alternative already, though.

Your HDMA implementation looks fine to me. I assume you've already figured out which channels the games H/DMA routines use, and have worked around that already. Writing to $2134, is, afaik, harmless. It doesn't do anything when written to as far as we can tell. There is no 3-byte transfer mode, of course.

By the way, I was recently directed to your webpage by a friend (-- kudos to your work so far by the way), and I noticed a few things you might have overlooked. For example, in your intro you use fullscreen 256x224x16 color images of the characters. I'm curious why you didn't go with 256x224x256 color images instead. Modes 3/4 should do this fine (be careful of offset-per-tile mode if you use mode4), a full image requires 0xe000 bytes of VRAM, and the tilemap only 0x400. You'd have extra room for a font on the other BG, too. Also, any reason you went with a static-width font?

Also, resizing the dialogue window to the full size of the screen to save an HDMA channel to set the left/right window positions for the cgaddsub effects was very clever. I had a game where I only had -one- channel that the game never used while a textbox was visible, and I ended up only making the dialogue box gradient fade. I would've made it use cgaddsub instead had I thought of that idea myself.

If you'd like some assistance with any of this, you can send me a PM with contact info and I'll get back with you. I have plenty of sample code for 256-color images and variable width fonts. I'm also kind of curious how you managed to get an mp3 into bof2 for your new intro. I've been wanting to do something like that for a while now. Since we both have expertise in different fields, perhaps we could help each other out? :)

[anomie]

Writing $2134 should be fine, the reg is read-only. It' should have about the same effect as reading say $2133.

Pseudo-hires is definately not emulated correctly in currently-released versions of snes9x, and probably not in zsnes. Currently released snes9x tries to play games with the color math registers, to try to make it render somehow in 1/2 addition mode. Correct emulation is to render a 512-pixel-wide screen, just like Mode 5/6 hires (which BTW currently released snes9x gets wrong as well -- correct emulation is to have main/sub only take 1/2 the pixels from the tile and force pseudo-hires on (mosaic acts slightly different though) rather than rendering a 512-pixel main and sub).

On a normal NTSC television, BTW, each hires pixel gets only 1/3 of one color subcarrier cycle. Thus the 'blending', so if you really want 100% accurate output you'd have to apply a filter that would duplicate that effect.

[d4s]

By the way, I was recently directed to your webpage by a friend (-- kudos to your work so far by the way), and I noticed a few things you might have overlooked. For example, in your intro you use fullscreen 256x224x16 color images of the characters. I'm curious why you didn't go with 256x224x256 color images instead. Modes 3/4 should do this fine (be careful of offset-per-tile mode if you use mode4), a full image requires 0xe000 bytes of VRAM, and the tilemap only 0x400. You'd have extra room for a font on the other BG, too. Also, any reason you went with a static-width font?

in the first place, i had static 256 color images in the intro.
however, i changed my mind and wanted to do something with animation cause static pics are rather boring.
most of the scenes consist of a 512x224 layer for the background and a 512x224 layer for the character and perform some smooth panning and scrolling.
having the characters tiles in 256 colors would be a tight fit cause some of the tilesets for one layer alone make up close to 32kb already in 16 colours.

imho, the characters look quite nice already, similar to a somewhat low-colored anime-style.

gideon asked why i didnt implement a vwf aswell.
to be perfectly honest, the reason is that i never coded one before
and bof2 doesnt seem to be a good game for vwf-starters.
the font tileset is fixed(there is some tile swapping going on, but the whole thing is very limited) wich would to my understanding require a total rewrite from scratch.
i guess i could do it, i just have the feeling that its lots of work for a little graphical difference.
would love to have a look at your vwf code, though.

at one point, i also thought about adding a hires textbox using mode5, but i figured that would mean to sacrifice the cgadsub gradient, so i canned that.

you can download an mp3 on the website, but im not actually decoding an mp3 on the snes, of course.
the whole song consist of one huge 6mbit brr sample.
in a nutshell, theres a sample in spc ram thats constantly written to.
the spc requests new sample data when due and i set the loop and end bits on the 65816 side if needed to simplify the audio data conversion process. this way, i can just convert a wav or mp3 song as a whole block, then split it
into small sample blocks at runtime instead of having to manually split and convert dozens of small samples.
i didnt invent that myself, either.
the idea is from a pd-rom and i rewrote it to include everything you need in a non-slideshow enviroment.(reset handler and such)

i can supply you with my code of course, but my style of coding is rather messy and unorganized, i dont know if you will be able to do much with it.

Also, resizing the dialogue window to the full size of the screen to save an HDMA channel to set the left/right window positions for the cgaddsub effects was very clever. I had a game where I only had -one- channel that the game never used while a textbox was visible, and I ended up only making the dialogue box gradient fade. I would've made it use cgaddsub instead had I thought of that idea myself.

well, bof2 is easy cause it hardly uses more than 2 hdma channels at once in town and overworld mode so i could safely assign them statically.

the battle mode is a bit different though.
although there are 4 channels left, various effects use different channels.
thats why i test the games hdma flags for free channels and pick a free one each frame.
never had the case that all channels were occupied.
but the most stuff during battle mode(moving the background to also appear below the status box and various main/subscreen stuff midframe) is done via irq, not hdma, anyway

thanks for the suggestions, guys!
i'll test that in super sleuth later.

[byuu]

most of the scenes consist of a 512x224 layer for the background and a 512x224 layer for the character and perform some smooth panning and scrolling.

Ah, sorry. I couldn't tell that from your pictures. You could easily keep the scrolling by just updating the right edges of the tilemap (much like a scrolling engine would), and mode3 has a 16-color BG2, so it would be -possible- to do the same thing, but very hard with the space available indeed.
And yeah, you did damn good for having only 16 colors.

and bof2 doesnt seem to be a good game for vwf-starters.
the font tileset is fixed(there is some tile swapping going on, but the whole thing is very limited) wich would to my understanding require a total rewrite from scratch.

A total rewrite isn't that bad, either. In fact, I actually find it easier than trying to work in the confines of the original text system. The first try is always the scariest. It's really nothing more than bit-shifting and combining. If it's a static tilemap, then I take it the game has no kanji? That does indeed make things harder, but I've made VWFs under the same condition. The image here was made on a fixed tileset. It's your game though, and if you don't think vwf is worth the trouble, I wouldn't bother. The biggest problem without a vwf is with the item system. It took me twice as long to double the width of items (by making 2 items/line -> 1 item/line) as it did to add vwf in the first place, but without one or the other, it looks like, well, a fan-translation...
The only reason I brought it up was because you mentioned you were trying to do the most advanced romhack ever. While it is extremely impressive, I've pretty much already done all that stuff and more to games already (sans the music player, which others have done), including variable-width fonts. I do think you can achieve that goal and make the best hack ever if you want, but a vwf is definitely a step in the right direction towards that goal. NoProgress even wrote a vwf routine that self-formats its own text! e.g.
"How are you doing, Bob?", or
"How are you doing,
ReallyLongName?"
o_O...
Besides, I'd love the (friendly) competition as I've already made that claim about Der Langrisser :D

at one point, i also thought about adding a hires textbox using mode5, but i figured that would mean to sacrifice the cgadsub gradient, so i canned that.

That's why I didn't even mention that idea in my reply. The only thing you could do if you did that was make a color gradient fade by using an HDMA on the palette registers.

Interesting with the music player. The biggest problem I have with other peoples' code is the sheer size. I can't work with a huge ass 200kb sample player, but if your code is reasonably small and does just what's needed, I'd love to see it.
I also don't have the tools/knowledge to split a wav into blocks and convert them to BRR :/
What do you use to do that?

well, bof2 is easy cause it hardly uses more than 2 hdma channels at once in town and overworld mode so i could safely assign them statically.

You are so lucky :/
For such a simplistic game, mine uses all -8- at different times (I fall back on solid-color boxes when this happens); albeit extremely rarely; as lots of special effects occur while the textbox is visible, even on the worldmap. However, by bumping the textbox over, I could just replace the palette fade with a cgaddsub fade, and it should work out great for most things :D

I'll upload some vwf code a bit later and PM it to you then, I suppose. I have probably about 30 of them by now, but they aren't really commented for a first-timer to look at, so I'll need to fix that first :/

[d4s]

A total rewrite isn't that bad, either. In fact, I actually find it easier than trying to work in the confines of the original text system. The first try is always the scariest. It's really nothing more than bit-shifting and combining. If it's a static tilemap, then I take it the game has no kanji? That does indeed make things harder, but I've made VWFs under the same condition. The image here was made on a fixed tileset. It's your game though, and if you don't think vwf is worth the trouble, I wouldn't bother. The biggest problem without a vwf is with the item system. It took me twice as long to double the width of items (by making 2 items/line -> 1 item/line) as it did to add vwf in the first place, but without one or the other, it looks like, well, a fan-translation...
The only reason I brought it up was because you mentioned you were trying to do the most advanced romhack ever. While it is extremely impressive, I've pretty much already done all that stuff and more to games already (sans the music player, which others have done), including variable-width fonts. I do think you can achieve that goal and make the best hack ever if you want, but a vwf is definitely a step in the right direction towards that goal. NoProgress even wrote a vwf routine that self-formats its own text!

after having a look at the vwf you sent me i really think it is worth the effort, thanks alot!

well, i didnt say i wanted to make the best romhack ever.
thatd be a goal thats doomed to failure right from the start.
im relatively new to romhacking (about 1 year) and even newer to coding.

however, there always has to be some kind of hype in order to
get people attracted, you know.
i know that most of the stuff im doing has been done already in one way or another, i just want to do something thats not a bare translation on the one hand, and no crippled hack that scares away the fans of the original on the other hand.
just something with an individual twist thats worth of playing the game again even if you didnt care about the grammatical flaws the original game had.

Interesting with the music player. The biggest problem I have with other peoples' code is the sheer size. I can't work with a huge ass 200kb sample player, but if your code is reasonably small and does just what's needed, I'd love to see it.
I also don't have the tools/knowledge to split a wav into blocks and convert them to BRR :/
What do you use to do that?

dont worry, its small.
but after having a look at your code, i feel somewhat ashamed to pass it over.
i'll comment it out and send it to you, though.
i just convert an mp3 or any other audio file to raw brr sample data using kode54s foobar 2000 adpcm plugin.
you just have to get rid of the header it appends to the file and get it into the rom.
i just split it into seperate 64k hirom banks cause wla dx doesnt allow files spanning over several banks.

[byuu]

after having a look at the vwf you sent me i really think it is worth the effort, thanks alot!

Yeah, the biggest mistake people make is telling themselves they can't do something. Everyone I know that I showed how to do VWFs have gotten the hang of it quickly and used it in all future games, one even uses it on 8x8 text, too. Well... except maybe one person.
If you don't think you can do something: make a backup of all your sourcecode, and give it a try anyway. You'd be surprised what you can do sometimes.

well, i didnt say i wanted to make the best romhack ever.
thatd be a goal thats doomed to failure right from the start.
im relatively new to romhacking (about 1 year) and even newer to coding.

Oh, sorry. For what it's worth, I don't doubt that you could do it if you really wanted to.
Nowadays with all the tools and documentation out there, one year is plenty of experience to get a lot of really awesome stuff done. Even great ASM hackers like Barubary couldn't pull off stuff like that cgaddsub text window you did.

i just want to do something thats not a bare translation on the one hand, and no crippled hack that scares away the fans of the original on the other hand.

Yeah, I really like enhancing the original games, and it's especially cool when you can fix longstanding bugs in the games sometimes, too. Didn't you even add in a fast-walking mode to the game? I bet Phantasy Star 3 fans (all 3 of them) would worship someone who could do that to that game :)

dont worry, its small.
but after having a look at your code, i feel somewhat ashamed to pass it over.

I'm sure your code is fine, I had like 3 comments in that entire file... as you can probably tell, I'm struggling with trying to find a way to make 65c816 assembly more c++-like, so the code is easier to read. So far, I only have the structural syntax somewhat working.

i just split it into seperate 64k hirom banks cause wla dx doesnt allow files spanning over several banks.

I don't think my SPC assembler allows files over 64k, either. I never assumed anyone would want more than 64k for an SPC binary image.
I would assume you'd be best to put the SPC program into an .asm file to compile with the SPC assembler, and then all the SPC data chunks into the .asm file to assemble with the 65c816 assembler.
That gives me an interesting idea though, it'd be kind of neat to merge the two assemblers together to allow mixing of spc + x816 assembly in the same file... it would be kind of funny to see stupid people try and jump to the SPC code via 65c816 jml/jsl, wouldn't it? :)

[kode54]

i just convert an mp3 or any other audio file to raw brr sample data using kode54s foobar 2000 adpcm plugin.
you just have to get rid of the header it appends to the file and get it into the rom.

More work may be necessary to turn that encoder into a useful SNES hacking utility.

For one, it should simplify finding or making smooth loops. Since the decoder does not reset itself to the exact state locked prior to the loop start block, as it can even loop back to a point before the sample start, or even after the loop end point. Thus, the encoder should also try to make the end block roll over to the start block as smoothly as possible. My encoder supports this to a degree, but foo_adpcm does not use it.

Also, it should account for the 25 samples lost from the end of one-shot samples. So, 25 samples worth of silence padding, or garbage if you're feeling brave and want to make some emulators clicktastic, then pad up to an even multiple of 16 samples. (Thanks Blargg. Yes, that's right, sample cuts off the last 9 samples in the block before the end bit is detected, unless the sample is looping.)

Source code is available, see foo_brr/brr.cpp, AdpcmMashS / AdpcmBlockMashI. Not sure if the encoder's result quantization/difference testing obeys the clipping constraints correctly, seems correct as far as libopenspc / Game_Music_Emu are concerned, which is based on testing. Otherwise, feel free to post, PM, or mail me corrections.

[neviksti]

Also, it should account for the 25 samples lost from the end of one-shot samples. So, 25 samples worth of silence padding, or garbage if you're feeling brave and want to make some emulators clicktastic, then pad up to an even multiple of 16 samples. (Thanks Blargg. Yes, that's right, sample cuts off the last 9 samples in the block before the end bit is detected, unless the sample is looping.)

I was not aware of this. Can you please elaborate for me?

Are you saying that the BRR block with the "End bit" set is not played? (this would be 16 samples then) Or just that the last 9 samples in the BRR block with the "end bit" set are not mixed into in the DSP 'output buffer' for some reason?

And, just to make sure I'm understanding. All the samples are played when the "end bit" and "loop bit" are set. Correct?

Most bizarre 'features' make sense from a design point of view after we understand the majority of the inner workings ... this one baffles me.

[kode54]

Are you saying that the BRR block with the "End bit" set is not played? (this would be 16 samples then) Or just that the last 9 samples in the BRR block with the "end bit" set are not mixed into in the DSP 'output buffer' for some reason?

The whole last block (end bit set) and the last 9 samples from the block before it. Earthworm Jim and Plok make some nice test cases. From Earthworm Jim, all the voice samples from What The Heck? and from Plok, drum samples used in both the Bonus Level and Akrillic themes.

And, just to make sure I'm understanding. All the samples are played when the "end bit" and "loop bit" are set. Correct?

Yes. It is my understanding that it only affects non-looping samples because of some look-ahead mechanism of the decoder, you'd have to ask Blargg about it. So, while it fully decodes looping samples, those non-looping samples will stop playing before complete decoded.

Most bizarre 'features' make sense from a design point of view after we understand the majority of the inner workings ... this one baffles me.

You got me there. I don't really understand it either. :D

[Overload]

It takes a number of cycles before each decoded sample is mixed. Is it possible that it takes say 15 cycles before mixing occurs. These samples may already be in the pipeline but because the sample decoder has already encountered an end of voice marker the channel is turned off and these samples disregarded.

[Nightcrawler]

Do 9 samples really matter? I mean we're talking a lost time of about 280us (micro seconds 9*(1/32000Hz), correct?