pouët.net

Some time ago I was looking at this video:
https://www.youtube.com/watch?feature=player_detailpage&v=XK4teEOTsFY#t=78

There's a blatant emulation error going on there, it seems that the game is changing the palette mid-screen to simulate translucent water (and of course the emulator disregards that). The problem is that as far as I know VGA doesn't have any reliable mechanisms to time raster effects to a given line. Does anybody know what could be being used here for timing?

Does anybody know of any other cases (games or demos) where raster effects are being used as well? (on PC, of course)

I changed palette a few times on screen in [url=http://www.pouet.net/prod.php?which=621651991 donut[/url].

See the comments for a link to my blog, which explains it somewhat. Basically I use a one-shot timer which I re-initialize at vbl every frame. It's not pixel-perfect, but you can get within a few scanlines accuracy across all computers, which is good enough.

That should be 1991 donut.

The VGA version of Lemmings changed the palette between the playfield and the status & icons so it could use 2x16 colours. (tries to "simulate" the 32 colours of Amiga)

I think the Pinball Fantasies menu screen did something similar to show two table logos at once with two different palettes. An even nastier trick must have been used for doing the same with the menu bar on the left...

http://www.pouet.net/prod.php?which=479
it changes graphics mode mid-screen. not sure if the plasma are raster-based though. however plenty of DOS-intros used raster registers (for vsync) and for rasterbars (especially textmode intros use rasters).

with the palette registers (0x3c8-0x3c9 iirc) and vsync i think you can achieve the desired effect.

or take a look at the overflow-register (0x3b5), it has a line-compare flag.

who know's what dosbox use for timing? yes, dosbox has rasterbugs. so real rasterbars won't show up there.

Pinball Fantasies' menu used one 16 color palette for the top half and another for the bottom half. The menu on the side didn't need any special handling because it used colors common to both palettes.

Scali already provided links to interrupt-based palette switching; for extra credit you can use VGA's ability to switch entire palettes at once. But if you just want to be dumb, you wait in a loop for horizontal retrace and then change a palette entry manually.

I guess OP had never seen "copper bars" in PC demos before?

raster? not at dosbox.

Actually DosBox supports it, just set machine=vgaonly :).

I will try to launch Kokoo BBStro.

The horizontal sync can be read from 0x3da:
http://www.ousob.com/ng/interrupts_and_ports/ng2d4da.php

TomoAlien: damn, you'r right. dunno if it was added in one of the later versions of dosbox. i am almost sure i didnt work on one of those.

g0blinish: its kukoo2.

.

@rudi, yes. I forgot a name..

rudi, use this build of DOSBox. It's much faster and stable that regular dosbox builds, and has support for VGA raster effects (and it's the only build which can run FastTracker I without black screen)

rudi: vgaonly has been part of DOSBox since at least the 0.7x versions. And it's not like there has been an official update for four years, so it's not exactly a "new" feature.

I just assumed they were done in software.

So, after analyzing two things, that leaves me with two questions:

1) Is the water in that game stable at all actually? Honestly I never saw the real thing so I don't know for sure, I just assumed there must have been something for timing because otherwise they wouldn't even try it.

2) How does the palette switching work? I mean, I get how it works in the 4bpp and lower modes, but what happens in 8bpp mode? Does it ignore the MSB of the pixels (to allow the switching) or doesn't it work at all? (if the latter, how would you use the 6-bit palette then?) The documentation wasn't very clear on how it worked.

You can a get stable raster interrupt by counting from vblank to the wanted number of horizontal blanks in a busy-wait loop, and measuring the time difference from the PIT i.e. programmable interval timer's counter register. Then subtract a little bit from the value you get and program a timer to happen at that time. Of course starting from a timer-based vertical blank interrupt, which is set up in the same way, only measuring the time between to vblanks. The timing is reasonably accurate, as long as you can disable interrupts and there's no multitasking crap going on in the background and keeping your program in a virtual 8086 sandbox. This started to be a problem after Windows 95 came around.

I don't get your palette question. Who cares how many colors there are in your palette. You change the RGB value behind color index 123, and then color number 123 is something else. MSB of pixels? What.

yzi: I think what he's referring to is that in 16-color mode, you can pick between several palettes, which requires one write, instead of writing all 16 colors manually. I don't think there is such a thing for 256-color mode?

Just recorded it a bit on an old dos machine seems there's a water effect.
http://youtu.be/CRjLJhC5vjA

The easiest solution I would assume to work would be to use 2 palettes of 128 colors, 1 regular and 1 blueish and midframe enable a bit in the pel mask register so you could switch between palettes using that with only a single register write.

The trick with color select register is that in 4bpp modes you can swap all 16 colors with one port write. Doing this manually for 16 colors takes usually slightly longer than one scanline.

Oh. Yes, I think the colors have to be written with just REP OUTSB into the color register. If you do this in the middle of the screen without waiting for hblanks - and there's only enough time to set a few colors inside the hblank - you'll get a little bit of noise on the screen. But if I remember correctly, it's possible to blank out the screen for this, so the color noise/flicker (or whatever the official term was) is effectively "hidden" behind a narrow black bar. The maximum REP OUTSB speed is different for each machine/VGA card.

The water level is moving quite slowly. You could just as well re-write the screen contents for the 100-200 or so changed pixels per frame, and switch them from underwater to normal or vice versa. ??

(but then again, why wouldn't it work on an emulator...)

IIRC 0x3c6 is anded with the color values and you could use that in theory to make 8 parallel checkerboards in 256 color mode. Unfortunately it doesn't work with most cards since a) nobody uses it and b) it's repurposed for hicolor stuff.

OK, looking at that video it seems like the left portion of the first water line is somewhat unstable... I guess that answers it.


Or just do what the Sonic games did on the Mega Drive (which suffers from the same defect): hide the palette garbage on top of water ripples (which have noisy looking graphics). It's very easy to miss.