Vesa 2.0, good for 3d lib?
June 18, 2006 10:05 PM Subscribe
I'm looking for information on Vesa 2.0, as far as usage in assembly (fasm) and c++ (gcc) goes. The reason i'm looking for this is because i'm interested in making a software rendered realtime 3d lib, so if you have any info on that (software libs) as well, it would be most helpful.
From what I remember, the VESA extensions just set up the given display mode (resolution and number of colors), and that's it. From there it's just a flat framebuffer that you move data into and out of. This will be slow as dogshit on any modern video card, but I guess you know that.
As far as gcc goes I'm not sure that it even supports the old segmented 16 bit "real" model. Unless you're in protected mode I wouldn't even bother trying. (Maybe extremely old versions of gcc do, but certainly not 3.x and 4.x.)
I too can't imagine why you'd be working with such an ancient 16 bit DOS environment, but everyone has their reasons.
posted by Rhomboid at 11:28 PM on June 18, 2006
As far as gcc goes I'm not sure that it even supports the old segmented 16 bit "real" model. Unless you're in protected mode I wouldn't even bother trying. (Maybe extremely old versions of gcc do, but certainly not 3.x and 4.x.)
I too can't imagine why you'd be working with such an ancient 16 bit DOS environment, but everyone has their reasons.
posted by Rhomboid at 11:28 PM on June 18, 2006
Writing directly on top of hardware without using ANY sort of library is just a pain in the ass. I spent a fair amount of time worrying about display modes compatibility back in the day, and it just sucks. Compatibility with that kind of thing isn't very good these days, either. Whatever you write probably wouldn't work on current windows.
A better idea would be to write a software 3d renderer on top of SDL. SDL gives you full access to a frame buffer, but abstracts all the display mode and portability concerns for you. Also, there's good documentation on that site. A friend of mine wrote a software renderer on top of SDL, and that combination worked out really well for him.
posted by JZig at 11:37 PM on June 18, 2006
A better idea would be to write a software 3d renderer on top of SDL. SDL gives you full access to a frame buffer, but abstracts all the display mode and portability concerns for you. Also, there's good documentation on that site. A friend of mine wrote a software renderer on top of SDL, and that combination worked out really well for him.
posted by JZig at 11:37 PM on June 18, 2006
Oh, and Crystal Space is a somewhat well written c++ 3d renderer, that either runs in software mode or on top of OpenGL. It might give you some ideas. You'll find that pretty much everything new in terms of 3d rendering is on top of either OpenGL or D3D.
posted by JZig at 11:41 PM on June 18, 2006
posted by JZig at 11:41 PM on June 18, 2006
Rhomboid: I've used this stuff with gcc. Well, with DJ Delorie's DJGPP port.
Anyway, yeah the DOS extender (go32) provided an int86() function to thunk into real mode, call the interrupt handler, and return to 32 bit protected mode.
I believe DPMI offers similar capabilities.
Ahhh, the those were the days. The technology was extremely awkward and irritating, but getting any realtime animation to work at all would just blow everyone's socks off. You kids today with your OpenGL and your YouTube and your ergonomic keyboards! Fah!
posted by aubilenon at 12:36 AM on June 19, 2006
Anyway, yeah the DOS extender (go32) provided an int86() function to thunk into real mode, call the interrupt handler, and return to 32 bit protected mode.
I believe DPMI offers similar capabilities.
Ahhh, the those were the days. The technology was extremely awkward and irritating, but getting any realtime animation to work at all would just blow everyone's socks off. You kids today with your OpenGL and your YouTube and your ergonomic keyboards! Fah!
posted by aubilenon at 12:36 AM on June 19, 2006
Yes, I'm aware of that. But DJGPP uses flat addressing / protected mode, which doesn't change the fact that gcc itself doesn't support the 16 bit segmented address mode.
posted by Rhomboid at 12:58 AM on June 19, 2006
posted by Rhomboid at 12:58 AM on June 19, 2006
I assume the poster would want to use 32-bit protected mode, so whether GCC supports 16-bit is immaterial. (Other than, of course, being able to call 16-bit software interrupts.)
Then again, the poster is apparently quite the luddite, so this may be an incorrect assumption.
Perhaps if the OP explained what they were intending this to be used for, it could help narrow down the appropriate technology...
If you're interested in learning about software rendering, or trying out something cool/new, the most productive route would probably be just writing your code using using Visual C++ Express (which is a free download) and DirectX (the 2d API, which used to be called DirectDraw, specifically.)
If you're more interested in learning low-level nuts-and-bolts type programming, I would recommend trying to do some homebrew console development, like, say, on the GBA. You could even write a software rasterizer on that.
Assuming you want to show this to anyone/use it for anything, either of those options would seem much more useful than something which relies on technology from 1995.
posted by blenderfish at 1:18 AM on June 19, 2006
Then again, the poster is apparently quite the luddite, so this may be an incorrect assumption.
Perhaps if the OP explained what they were intending this to be used for, it could help narrow down the appropriate technology...
If you're interested in learning about software rendering, or trying out something cool/new, the most productive route would probably be just writing your code using using Visual C++ Express (which is a free download) and DirectX (the 2d API, which used to be called DirectDraw, specifically.)
If you're more interested in learning low-level nuts-and-bolts type programming, I would recommend trying to do some homebrew console development, like, say, on the GBA. You could even write a software rasterizer on that.
Assuming you want to show this to anyone/use it for anything, either of those options would seem much more useful than something which relies on technology from 1995.
posted by blenderfish at 1:18 AM on June 19, 2006
Response by poster: This is something that I intend to run in windows, I had been messing with Vesa a little in fasm, and it seemed to work quite well. What brought on the whole thing was...... I was messing around coding some demo/gfx effects in asm, and got curiouse about how i could create a screen that was bigger than mode 13h, like say 800x600x16k (16k being 16000 color) or even truecolor... i asked around in a forum that i frequant, and someone showed me an example of Vesa, it really sparked my interest. About software rendering in general, I'm wanting to make a 3d engine that's software rendered for games and demo's that works in windows, but is also highly portable. sorry if this post is incoherant babble and the speeling, i just rolled out of bed :S
posted by xteraco at 4:48 AM on June 19, 2006
posted by xteraco at 4:48 AM on June 19, 2006
You know, on a PCIe machine, VESA would probably be smoking fast... assuming it works how I think it does, where you use the VESA calls to set up the frame buffer, and then access the hardware directly from there.
I don't think you'd need to be in 16-bit mode except for the original calls, would you? Once it's set, you can write to that memory in any mode.
God, a PCIe interface... talking directly to the video hardware... with NOTHING ELSE going on but your own code... you could do some seriously impressive shit. Everything in modern machines is abstracted through multiple layers, each exacting a toll on processing power. We don't often see how truly fast computers are these days.
This stuff was really, really slow on a 16Mhz 386 with an 8Mhz, 16-bit bus. With a 3600Mhz CPU on a 40 gigabit bus (PCIe x16), however, I think things might be just a leeeetle bit quicker.
posted by Malor at 5:42 AM on June 19, 2006
I don't think you'd need to be in 16-bit mode except for the original calls, would you? Once it's set, you can write to that memory in any mode.
God, a PCIe interface... talking directly to the video hardware... with NOTHING ELSE going on but your own code... you could do some seriously impressive shit. Everything in modern machines is abstracted through multiple layers, each exacting a toll on processing power. We don't often see how truly fast computers are these days.
This stuff was really, really slow on a 16Mhz 386 with an 8Mhz, 16-bit bus. With a 3600Mhz CPU on a 40 gigabit bus (PCIe x16), however, I think things might be just a leeeetle bit quicker.
posted by Malor at 5:42 AM on June 19, 2006
Oh, if that's what you want to do what I recommend is use SDL to initialize your video subsystem and blit your framebuffers, and do everything else in software.
SDL is kind of limited if you're doing advanced stuff, but that fact makes the APIs super easy to learn and use. If you're even a teeny bit careful everything will compile right off the bat on other platforms. This also gives you good portable mouse IO, asynchronous keyboard IO, and if you want it joystick and timing stuff.
At least as of 1999, that was totally the way to do software rendered graphics easily and portably. :D
posted by aubilenon at 6:19 AM on June 19, 2006
SDL is kind of limited if you're doing advanced stuff, but that fact makes the APIs super easy to learn and use. If you're even a teeny bit careful everything will compile right off the bat on other platforms. This also gives you good portable mouse IO, asynchronous keyboard IO, and if you want it joystick and timing stuff.
At least as of 1999, that was totally the way to do software rendered graphics easily and portably. :D
posted by aubilenon at 6:19 AM on June 19, 2006
This thread is closed to new comments.
Also maybe Ralf Brown's Interrupt List might help you..
I'm curious what you could possibly be doing.
posted by aubilenon at 10:30 PM on June 18, 2006