Can I download this game from somewhere? (I guess, not.)

the game complains about being unable to create a sprite buffer when using dgVoodoo and is missing most of the graphics

Sounds like a palette handling incompatibility between dgVoodoo and native DX.

The graphics that suffer the corruption are pallettised bitmaps using external palette files. Each palette file contains groups of 16 palette entries, each entry being made up of three 8-bit values

Or the game uses palettes with non-8 bit indices that weren't supported by ancient hw but were emulated by DX, maybe.
(dgVoodoo supports palettes only with 256 entries.)

I just thought I'd point to this video on Youtube (not mine), as it displays the problem: https://www.youtube.com/watch?v=zeiiIRsa7HU

The video's fuzzy but the problem's really clear around 2:30.

I've tried this game with dgVoodoo.
It didn't work but I found and fixed 2 bugs and now it runs beautifully.

Except the wrong palettes of some background and the characters.
This game does not use paletted bitmaps through DirectDraw at all but uses 16bit RGB bitmaps so the conversion from paletted bitmaps to RGB has to be done by the game itself (probably through GDI).

I don't understand how this game could work under Win98 because:
- it supplies an invalid argument for one of the surface creation at startup, that's why I can't run it with native DX either (this was one of the 'bugs')
(my only guess is that DDraw of Win9x line slightly differed from the one introduced in WinNT)
- since the bitmap conversion is not done through DDraw it must have been wrong in Win98 too... It didn't matter if I started the game in Win98 compat mode or with forced 256 color desktop.
(my only guess is some incompatibilites between 98/NT GDI's but I can hardly believe that)

Hmm, weird. Unfortunately I can find virtually no screenshots online, and no video of it running on old hardware. Two shots show up on Google image search that look correct, so it looks like someone had it running correctly at some point.

It's just bizarre that the game seems to be using the palette entries offset by one position. It made it simple to fix but it's weird; I almost wondered if it could have been some kind of obscure copy protection that malfunctions under NT based systems. I doubt it though.

Thanks for taking a look at the game.

Hi,
I was redirected here from the main dgvoodoo2 topic, I have the game and I share the same problems mentioned earlier.

@Silanda: Since the game now starts correctly thanks to Dgvoodoo2 and other ddraw wrappers, I'm particularly interested in your palette fixing method: please can you make a tutorial?
Can I edit the files with an hexeditor or do I need more sophisticated tool?

Dege wrote:

I don't understand how this game could work under Win98 because:
- it supplies an invalid argument for one of the surface creation at startup, that's why I can't run it with native DX either (this was one of the 'bugs')
(my only guess is that DDraw of Win9x line slightly differed from the one introduced in WinNT)

Nah, I tried this idiot in a real Win98se + s3 virge dx/voodoo2 machine and it doesn't start: it nags (as always) about "trying to run in one resolution while the screen is trying to force to be another resolution" (rough japanese to english translation). This happens on all systems I tried it on except for an old Toshiba tiny netbook (Xp32 with intel integrated card). 😳

I was actually able to get this game to run in Windows 98 under PCem, and it did run correctly without modifying the palette files, so the game is doing something weird.

I can try to make a tutorial if you like, or I can just upload my already modified palette files. The hex editing isn't hard to do, it's just a bit tedious. Also, there are still small glitches in some backgrounds, even with the modified files. This isn't a bug dues to running in modern Windows though, this is due to the way they assigned different palette entries to different sprites in the background + their animations. It's possible to improve things, but it's impossible to restore the backgrounds to exactly how they looked in Advanced V.G.2. At least, not without knowing how to reassign different sprites to different palettes, which I don't have a clue about.

Sure, if you want upload modified palette, I'd be happy 😁

Myloch wrote:

Sure, if you want upload modified palette, I'd be happy 😁

Ok, here they are. These should be the files, just copy the directories into them into the game's data subdirectory and overwrite the original files.

Silanda wrote:

Also, there are still small glitches in some backgrounds, even with the modified files. This isn't a bug dues to running in modern Windows though, this is due to the way they assigned different palette entries to different sprites in the background + their animations. It's possible to improve things, but it's impossible to restore the backgrounds to exactly how they looked in Advanced V.G.2. At least, not without knowing how to reassign different sprites to different palettes, which I don't have a clue about.

Don't worry, this game port is terrible to begin with: it lacks A LOT of fancy graphical effects Advanced VG 2 for psx had. Sometimes this game made me think of Mugen (if you know what it is). However the glitches you talked about are so subtle I cannot even notice them: maybe you mean Chiho stage for example? Windows are black and there is nothing outside, the result is ugly as hell 🤣

Other tham that, there is huge improvement now and you did amazing job, thanks for sharing!

I'm going to check out Chiho's stage to see if anything can be done about that. That one actually doesn't use any 16 colour bitmaps with separate palette files, just 256 colour bitmaps. The one I was thinking of was Manami's stage, where the colours on some of the background sprites would flash. However, it seems that I'd tried to fix that, so it's not perfect with the fix but it's better than it was.

EDIT: I don't think I'll be able to fix Chiho's stage. The graphic files are there, so I thought that perhaps the wrong palette entry was assigned to the windows, but that doesn't seem to be it as they are assigned the transparent palette entry in both the .bmp2 and .vgc files. The stage doesn't work correctly on PCem either, so it seems that it was always screwy.

Silanda wrote:

I was thinking of was Manami's stage, where the colours on some of the background sprites would flash

I checked: nothing flashes here on manami's stage. But I used DxGl wrapper (otherwise the game doesn't start here). So maybe that's why there's no flashing colors here.

Myloch wrote:

Silanda wrote:

I was thinking of was Manami's stage, where the colours on some of the background sprites would flash

I checked: nothing flashes here on manami's stage. But I used DxGl wrapper (otherwise the game doesn't start here). So maybe that's why there's no flashing colors here.

You won't see it with my fixed files because I fixed it. I did this all last year, but IIRC the colours of two of the background sprites aren't quite right. I had to either change their colours or the colours of the kid with the balloon.

I fixed a problem in Manami's stage, a background layer (castle) was incorrectly placed.

Silanda wrote:

I don't think I'll be able to fix Chiho's stage. The graphic files are there, so I thought that perhaps the wrong palette entry was assigned to the windows, but that doesn't seem to be it as they are assigned the transparent palette entry in both the .bmp2 and .vgc files. The stage doesn't work correctly on PCem either, so it seems that it was always screwy.

There are also some animations (the boys and the girls drinking) that were never used instage. I'm thinking of a brutal solution...

Nice work. I'd never really noticed that because it almost looked like the gap was supposed to be a lake.

Damn, this game is sloppy; there's another bug in Manami's stage: the animated Ferris wheel is on the wrong layer, in front of the nearby building. It's fixable if the position of the wheel relative to the building and the trees in the background can be figured out, and then pixels are deleted accordingly.

A better solution would be to understand where layer priorities informations are stored.

Fixed cloud in Reimi's stage: simulated partial transparency (now it's more similar to psx version), instead of fugly solid colors cloud.
Lazy japanese programmers: the game included correct cloud in stage archives, to be more precise the game includes most if not all graphics of original advanced variable geo 2 stages, but some background elements are not implemented on pc port.

Yeah, it looks like they just ripped Advanced V.G. 2's graphic elements and implemented them extremely lazily. The graphics for Chiho's stage contain what should be transparent elements as well as the missing backgrounds, but they go unused since this engine doesn't seem to support real transparency.

What I find puzzling is that this game is about as lazy as can be, yet V.G. Max actually seemed to have had quite a lot of effort put into it. It's strange because Max, with its brand new super deformed graphics, would probably have had less appeal than Custom.

Nice work on the clouds!

Here's a quick and dirty experiment with Chiho's stage. It's probably possible to improve, but I think it looks a fair bit better. You might want to back up your original file first.

Silanda wrote:

Here's a quick and dirty experiment with Chiho's stage. It's probably possible to improve, but I think it looks a fair bit better. You might want to back up your original file first.

And here's a slightly improved version.

Thanks!
Interesting how in the ps1 version they forgot to draw exterior of 1 window too, lower-left one.
https://www.youtube.com/watch?v=3GQEP38elug