Just saw that on you Youtube. Intesresting effects, but resolution is pretty low (128x96). The second one is quite interesting though...
[youtube]http://www.youtube.com/watch?v=yK2MMMTw3SY[/youtube] [youtube]http://www.youtube.com/watch?v=pgAvTf52SgE[/youtube]
Uze
XGS AVR "Ultra Demo"
Re: XGS AVR "Ultra Demo"
Yea, I saw those; pretty impressive tech demos given that they're using the same specs we are! But you have to admit: that's some pretty slick raycasting going on there for #2. I wonder if it would be possible to do a whole map rather than repeat one tile: F-zero anyone?uze6666 wrote:Just saw that on you Youtube. Intesresting effects, but resolution is pretty low (128x96). The second one is quite interesting though...
Anyway, by halving the vertical resolution like that, it's almost like cheating. That's just gobs of extra cycles per line that get used for rendering, oh I don't know, 15 or more sprites to a secondary line buffer... and that's just based on the mode2 code. I'd be tempted to do that for my project if it wouldn't make Simon take up half the screen.
But we can totally do that wavy effect thing under some of the existing video modes on the Uzebox. I'm planning on it for the hirez sections in mode5. Something like 3 bits on the section flags byte for the sine wave amplitude, and a zen timer to control the phase, which then gets added to the x-scroll per line. The mirror effect is just an invert on the line counter per section - that wouldn't be too hard either.
Tango D Library http://www.dsource.org/projects/tango
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
-
- Posts: 252
- Joined: Tue Dec 02, 2008 12:38 am
- Location: Carlsbad, California (USA)
Re: XGS AVR "Ultra Demo"
Pretty bizarre resolution choice? 128x96?
Well, I guess it makes a certain amount of sense, since you get to keep a decent aspect ratio. Any idea what sort of timings they're using? ie are they scan-doubling and insetting the screen? 8, 9, or 10 cycles per pixel?
Also seems like it would be really easy to retarget to a cheap LCD screen too.
-Dave
Well, I guess it makes a certain amount of sense, since you get to keep a decent aspect ratio. Any idea what sort of timings they're using? ie are they scan-doubling and insetting the screen? 8, 9, or 10 cycles per pixel?
Also seems like it would be really easy to retarget to a cheap LCD screen too.
-Dave
Re: XGS AVR "Ultra Demo"
Considering it runs at the same overclocked speed as the Uzebox, this amount to ~11cycles per pixel for a 128 pixel wide resolution. Now, as pragma noted, scan lines are doubled per field, so (theoretically) you get double the cycles per line. Does that mean...22 cycles per pixel in the end?
But seriously, 128x 96...that too low. Look at the Mario picture on my main site, man it's almost a fifth of the screen tall!
Btw, anybody knows how the color is generated? From the XGS site the schematics picture is so crappy, it's impossible to read. Perhaps it explains the low resolution.
Uze
But seriously, 128x 96...that too low. Look at the Mario picture on my main site, man it's almost a fifth of the screen tall!
Btw, anybody knows how the color is generated? From the XGS site the schematics picture is so crappy, it's impossible to read. Perhaps it explains the low resolution.
Uze
Re: XGS AVR "Ultra Demo"
Pretty close. Assuming an A/B buffering scheme, where you render to buffer A while you read out from B and vice-versa, they can do a good deal of rendering. Assuming a software architecture like we have for mode2, that's enough time for 12 or so sprites per line - maybe more. It's also well suited to the painter's algorithm, allowing for full overlapping of sprites.uze6666 wrote:Considering it runs at the same overclocked speed as the Uzebox, this amount to ~11cycles per pixel for a 128 pixel wide resolution. Now, as pragma noted, scan lines are doubled per field, so (theoretically) you get double the cycles per line. Does that mean...22 cycles per pixel in the end?
The VGA out is functionally similar to NTSC, in that it has vsync and hsync signals, but the RGB color data is transmitted on their own pins; so no need to plex all that crap together into a luna/chroma/burst signal. This arrangement is ideal for pin-twiddling on something like the AVR, so I think they're generating the VGA timings in-band kind of like we are for NTSC.Btw, anybody knows how the color is generated? From the XGS site the schematics picture is so crappy, it's impossible to read. Perhaps it explains the low resolution.
In fact, I'd wager that thanks to your use of the NTSC encoder chip, the raw output of the AVR on the Uzebox is already very close to VGA compatible.
Tango D Library http://www.dsource.org/projects/tango
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
Re: XGS AVR "Ultra Demo"
Hmmm, fair enough for VGA, but I was more wondering about the composite video output. I'm gessing it uses some sort of johnson counter for the NTSC phase control?
Uze
Uze