VOGONS

Search

Common searches

Search results

Display options

Display options

Re: SVGA/VESA programming

Posted on 2022-06-22, 11:39

Ouch, a typo, yes, it should have been less than 1/4. Probably had too high expectations forgetting how even commercial games had trouble on the 486. Games like Little Big Adventure or Transport Tycoon definitely redrew the screen for every frame and must have employed very optimised assembler …

Re: SVGA/VESA programming

Posted on 2022-06-22, 07:42

Or is it okay to draw all the screen for every frame? Background, sprites and all? It did work in VGA 320x200, I think even on a 486, but that was less than 1/2 of the pixels. I am afraid it would give me like 5-10 FPS on the Pentium, if even that many. You have to try. I always use this double …

Re: SVGA/VESA programming

Posted on 2022-06-22, 07:36

Or is it okay to draw all the screen for every frame? Background, sprites and all? It did work in VGA 320x200, I think even on a 486, but that was less than 1/2 of the pixels. I am afraid it would give me like 5-10 FPS on the Pentium, if even that many. You have to try. I always use this double …

Re: SVGA/VESA programming

Posted on 2022-06-22, 05:18

in its time, vesa was not really a thing on 286 VGA cards, so I've only ever done VESA programming in pmode using the linear framebuffer. bank switching is just a pita and slows things down. since your not targeting a 286, not using the LFB seems like punishment :) I'll have to dig around, I have …

Re: SVGA/VESA programming

Posted on 2022-06-22, 05:11

If you need to do large blitting operations then just adding is of course much cheaper, or rather you could even rep stosb or rep stosw if you precompute the number of pixels you can blit before a line or page change is necessary. However on a 486 a mul is really cheap. On 8086 and 80286 you can …

Re: SVGA/VESA programming

Posted on 2022-06-22, 05:09

and this part scr_pos += (640 - x2) + x1; is one of the reasons I kept asking you about the memory arrangement when the width of the virtual screen is greater than the resolution width. I still do not understand the problem and why you need 'memory arrangement' info. 1. Let's suppose you already …

Re: SVGA/VESA programming

Posted on 2022-06-21, 13:33

I have always read that "mul" is too costly and that one should avoid using it when possible. So I went for "shl"s to compute the coordinates into one offset and then loops to get the bank nambur. Yes, it's not the fastest instruction (especially not on P1) but it's not that slow as e.g. a div/idiv …

Re: SVGA/VESA programming

Posted on 2022-06-21, 13:30

I have always read that "mul" is too costly and that one should avoid using it when possible. So I went for "shl"s to compute the coordinates into one offset and then loops to get the bank nambur. But as you say, it is a deditated instruction. Still, I am probably failing to explain my goal - I …

Re: SVGA/VESA programming

Posted on 2022-06-21, 11:17

I have a PutPixel separately for 640x, 800x and 1024x (not that I would ever need those) just to avoid that costy "mul" and split it into "shl"s, which reqires a constant number to work with. Hi, I have the strong feeling that your bank finding algorithm is more costly than that simple mul. That …

Re: SVGA/VESA programming

Posted on 2022-06-21, 06:16

Wow, I dont even know many of the asm commands you use there, never seen floating point maths in asm before! And the maths part of it is way over my head, but I can see how you draw to the four screens as parts of the large virtual one and then switch to them, this is helpful. Also how you can just …

Re: SVGA/VESA programming

Posted on 2022-06-21, 06:05

Neat! Thank you for the tips and examples, I will try it on my real PC when I get the chance again. And also here in DOSBox. As you apparently have experiences with this, how do you go about using it for double buffering? I mean you probably set the start offset from 0 to 307200 and back (for …

Re: SVGA/VESA programming

Posted on 2022-06-21, 05:34

The few games I was able to get working with VESA graphics were so much easier on the eyes than the regular graphics. TIE Fighter, especially, as the craft looked smoother and had a more life-life feel. I think Dark Forces may have had a hidden VESA mode, as when I played it in Windows and moved …

Re: SVGA/VESA programming

Posted on 2022-06-21, 05:32

Tried the three programs you posted, the rotary thingy is very cool, even not considering your expert-level VESA access! And after some more reading it seems that while you can access more of the memory, hence have another screen buffer, you access it as a chunk of memory with bank switches, which …

Re: SVGA/VESA programming

Posted on 2022-06-20, 13:13

It seems that the virtual screen functions are available only from VESA 2.0 up, my S3 Trio with VESA 1.2 probably wont even return the info in the mode struct. I wrote the struct definition following the VESA 1.2 specification which is why I even missed those fields connected with the offscreen …

Re: SVGA/VESA programming

Posted on 2022-06-20, 11:04

I think you can do double buffering in 640x400 IF the VBE mode returns at least eight 64KiB banks of video memory (512KiB). You can use function 07h to set the screen start to flip back and forth between the pages (or even implement soft scrolling vertically). 6.9 Function 07h - Set/Get Display …

Re: SVGA/VESA programming

Posted on 2022-06-20, 11:03

Hi, No. Look at the ModeInfoBlock definition in the documentation: ModeInfoBlock struc ; Mandatory information for all VBE revisions ModeAttributes dw ? ; mode attributes WinAAttributes db ? ; window A attributes WinBAttributes db ? ; window B attributes WinGranularity dw ? ; window granularity …

Re: SVGA/VESA programming

Posted on 2022-06-20, 09:16

Of course, I do, but not at hand. My aim is for it to work on the real PC, using DOSBox only as an alternative as I only have access to the real PC a few times per year. True with 640x400, yet now facing the problem with maybe no access to double buffering and perhaps no way to solve it another way …

Re: SVGA/VESA programming

Posted on 2022-06-20, 08:46

Hi, This is not true. Even in real mode you can achieve hardware assisted double, or even triple buffering in some modes (depending on the size of available video memory). You do not need protected mode for this. The necessary functions have been available from VESA 1.2 (that version did not define …

Re: SVGA/VESA programming

Posted on 2022-06-20, 07:45

How did I miss that?? Thank you! Will have to look into that then. I want to keep the requirements low, but VESA 1.2 is totally okay and a 256kB gfx card wont cut it in 640x480x8 anyway. Would be nice to keep it down to 512Kb, but 2x640x480 = 600kB so I guess 1MB would be the requirement then.

Page 4 of 6

Go to top of page Go to top of page
Close window
Close window