Soft Body Pressure Model (Discussion on new video mode too!)

[Jhysaun]

Look at this amazing paper: http://panoramix.ift.uni.wroc.pl/~maq/soft2d/index.php

If we ever get some type of vector videomode on the Uzebox, I am definitely going to try this.


By the way, I've had this idea on jow to implant a vector video mode for a while. If you transform bresenham's line algorithm (http://en.wikipedia.org/wiki/Bresenham% ... _algorithm) to run from top to bottom (instead of left to right) than couldn't we have a video mode that solves which pixels are on in the hsync. It would only have to solve the next scanline. We could just store variables like deltax and y in memory and each hsync we can pick up where the last one left off.

[DaveyPocket]

Awesome!
Your idea seems like it should work. We do need some sort of vector engine.

[pragma]

By the way, I've had this idea on jow to implant a vector video mode for a while. If you transform bresenham's line algorithm (http://en.wikipedia.org/wiki/Bresenham% ... _algorithm) to run from top to bottom (instead of left to right) than couldn't we have a video mode that solves which pixels are on in the hsync. It would only have to solve the next scanline. We could just store variables like deltax and y in memory and each hsync we can pick up where the last one left off.

I think that would be very doable, but I wonder how it would compare with a simple monochrome screen buffer and performing all the rendering during vsync.

[Jhysaun]

I think that would be very doable, but I wonder how it would compare with a simple monochrome screen buffer and performing all the rendering during vsync.

huh? I guess that would work. I thought of that, but when I did the math last night I figured there was barely enough memory to do a 30 x 30 screen. Thats what I get for trying to think at three in the morning . I think 180 x 135 (180/135 is proportional to 800/600) is a decent resolution that keeps enough ram for program usage.

8 * 4096 = 32768 bits in RAM.
180 * 135 = 24300 bits for PLOTSCREEN
32768 - 24300 = 8468 bits left for program usage.

>J

P.S Anyone know how much ram other video modes use?

[Jhysaun]

So I've put some more thought into this, and instead of having monochome, why don't we have 2 different colors on each scanline? We can have it display one color if that pixel is on, and another if that pixel is off. We can store the two colors for each scanline. Another idea (since 2 bytes for 135 scanlines really adds up) is we can add support for gradients. Ex. Scan line 1 could be 00000000 (black) and scanline 100 could be 11100000 (Bright Red) Then we could have a nice gradient go from scan lines 1-100. In the hsync we could calculate the colors of the next scan line.



Anyone know about algorithms for solving gradients?


>J

[pragma]

So I've put some more thought into this, and instead of having monochome, why don't we have 2 different colors on each scanline? We can have it display one color if that pixel is on, and another if that pixel is off. We can store the two colors for each scanline. Another idea (since 2 bytes for 135 scanlines really adds up) is we can add support for gradients. Ex. Scan line 1 could be 00000000 (black) and scanline 100 could be 11100000 (Bright Red) Then we could have a nice gradient go from scan lines 1-100. In the hsync we could calculate the colors of the next scan line.

Honestly, I can't think of another way to do it. If you don't mind sacrificing some horizontal resolution in the margins, like mode2, then you can get a few more cycles for managing the palette for each line/section.

Good luck with bulding a new screen mode though. Just don't do what I did; make sure your test program always makes some kind of sound/music so you can be sure you're not clobbering the audio mixer.

Anyone know about algorithms for solving gradients?

Back in the day, we just applied a sin() function to the various color components to get non-linear gradients for "copper bar" demos. In our case you can just hijack the 256-byte sin wave buffer used by the sound engine for a fast solution. But even a just linear interpolation of each color component, between any two colors, works pretty well. The trick is to use "fixed point" math, or a variation of the bressenham line function to do the actual interpolation.

[uze6666]

Before the movie player video mode, I was fiddling with a "vector" mode. It's very similar as you guys are describing. It's 240x224 resolution using 256 monochrome ramtiles. Background color (non-set pixels) can be set per scanline using a 224 bytes buffer that defines the bg color to be used for each scanline. Note it could also use a small callback hook to set the color. So with that it's trivial to have some simple vector lines with copper bars going on in the background.

It's unfinished but I'll add it anyways to gCode if anyone is interested.

Uze

[Jhysaun]

It's unfinished but I'll add it anyways to gCode if anyone is interested.

Im interested