root42 wrote on 2022-06-22, 06:56:

Falcosoft wrote on 2022-06-22, 06:29:

You have to try. I always use this double buffering 'flip' concept and redraw full pages. But I must say I do not think that ban […]
Show full quote

WhiteFalcon wrote on 2022-06-22, 05:09:

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 buffering 'flip' concept and redraw full pages. But I must say I do not think that banked 640x480 256 color mode on a 486 (and 20+) fps is a realistic expectation. VGA 320x200 has less than 1/4 of the pixels (not 1/2). I think even the linear frame buffer mode of 640x480 could have performance problems on a 486.
I do not know your exact program and what your Store_xxx and Restore_xxx routines do but one thing is sure: Never read from video memory if performance is important. Writing to video memory is typically faster than writing to system memory but reading from video memory is always much slower than reading from system memory. So make sure your store routines do not save the video buffer.
BTW you can also use 320x240 VESA mode the same way as 640x480 and with some additional work you can offer your users a low-res and a high-res mode as selectable options.

Good idea. Or even 640x400 as I mentioned above. If you are coding an adventure game (inventory comes to mind) you don't need to do full screens, and even the 20 FPS is not that important. I think that is very well doable on a 486, if you refrain from too large sprites or full screen scrolling and redraws. Also, color cycling can animate large swaths of image... 😀

True. I know myself enough to expect I will hit some wall and stop long before I create anything resembling a game, but that wont stop me from going there 😁 As they say, the road is sometimes more important than the goal. Nevertheless the goal is a photo-based point-and-click relaxation adventure game in the vein of, lets say, Lost in Time, Ween, Shannara, Death Gate, or perhaps the Infocom adventures (albeit with photographic graphics). The FPS is important mostly for the mouse cursor (when holding an item) to move smoothly. Dont think there would be much else animating. 640x400 would be a little faster and vram friendly, I still somehow prefer the look of that x480 with its square pixels 😀

WhiteFalcon wrote on 2022-06-22, 07:36:

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 routines I guess.

Actually no. LBA only redrew parts where animated objects were, and left the rest alone. In the low-res mode it even used hardware scrolling by panning the viewport over the whole framebuffer. When moving off the screen it would redraw and not scroll. And Transport Tycoon probably worked in a very similar fashion. Full screen redraws are RARELY necessary outside of things like flight simulators or other 3D games, where the whole scene changes with moving perspective.

EDIT: And yeah it used C and Asm for its code, which you can look at here: https://github.com/2point21/lba1-classic/tree … LIB386/LIB_SVGA -- this is the svga routines, but the repo has the FULL source code! 😁

EDIT2: Hm, maybe they did not use mode x. I have to dig a bit deeper. It certainly used to scroll pretty smoothly so I thought they might be using it! 😀

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen:

1Mcga_Flip		proc	uses	esi edi
2
3			mov	esi, Log
4			mov	edi, Phys
5
6			mov	ecx, 64000/4
7			rep	movsd
8
9			ret
10Mcga_Flip		endp

root42 wrote on 2022-06-22, 08:51:

Actually no. LBA only redrew parts where animated objects were, and left the rest alone. In the low-res mode it even used hardwa […]
Show full quote

WhiteFalcon wrote on 2022-06-22, 07:36:

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 routines I guess.

Actually no. LBA only redrew parts where animated objects were, and left the rest alone. In the low-res mode it even used hardware scrolling by panning the viewport over the whole framebuffer. When moving off the screen it would redraw and not scroll. And Transport Tycoon probably worked in a very similar fashion. Full screen redraws are RARELY necessary outside of things like flight simulators or other 3D games, where the whole scene changes with moving perspective.

EDIT: And yeah it used C and Asm for its code, which you can look at here: https://github.com/2point21/lba1-classic/tree … LIB386/LIB_SVGA -- this is the svga routines, but the repo has the FULL source code! 😁

EDIT2: Hm, maybe they did not use mode x. I have to dig a bit deeper. It certainly used to scroll pretty smoothly so I thought they might be using it! 😀

Good find! I was just searching for the source code of LBA. I remember the whole screen only changed on demand or when necessary, yes, but the sprites moved around constantly without any noticeable artifacts. Also the game required only 512kB vram which in itself means no double buffering (not in vram anyway). I wonder how they achieved this. As the source is much more ASM than C, I cant figure out much. If you manage to learn more how they achieved the smoothness without any tearing or blinking, I am all ears 😀
TTycoon is a different beast though, they must have needed to redraw the screen almost constantly with so much happening in bustling cities and also with allowing the user to drag the whole landscape around. Magic. No other explanation.

EDIT: Maybe my eyes are pink-tinded with nostalgia and there were some artifacts, will have to try on the real PC when possible.

root42 wrote on 2022-06-22, 09:12:

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen: […]
Show full quote

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen:

Copy code to clipboard

1Mcga_Flip		proc	uses	esi edi
2
3			mov	esi, Log
4			mov	edi, Phys
5
6			mov	ecx, 64000/4
7			rep	movsd
8
9			ret
10Mcga_Flip		endp

64000/4 means ModeX, right?

WhiteFalcon wrote on 2022-06-22, 11:39:

Good find! I was just searching for the source code of LBA. I remember the whole screen only changed on demand or when necessary, yes, but the sprites moved around constantly without any noticeable artifacts. Also the game required only 512kB vram which in itself means no double buffering (not in vram anyway). I wonder how they achieved this. As the source is much more ASM than C, I cant figure out much. If you manage to learn more how they achieved the smoothness without any tearing or blinking, I am all ears 😀

I am trying to figure it out. I think they have the framebuffer in main memory and blit at least parts every frame. Still trying to figure it out... It doesn't help that variables and comments are mainly in french 😁

WhiteFalcon wrote on 2022-06-22, 11:43:

root42 wrote on 2022-06-22, 09:12:

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen: […]
Show full quote

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen:

Copy code to clipboard

1Mcga_Flip		proc	uses	esi edi
2
3			mov	esi, Log
4			mov	edi, Phys
5
6			mov	ecx, 64000/4
7			rep	movsd
8
9			ret
10Mcga_Flip		endp

64000/4 means ModeX, right?

No, it means 320x200, but not mode x in this case, as they use the plain old 13h mode. The /4 is only because they rep movsd, which move 4 bytes at a time. That means 64000/4 repitions.

root42 wrote on 2022-06-22, 11:51:

WhiteFalcon wrote on 2022-06-22, 11:43:

root42 wrote on 2022-06-22, 09:12:

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen: […]
Show full quote

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen:

Copy code to clipboard

1Mcga_Flip		proc	uses	esi edi
2
3			mov	esi, Log
4			mov	edi, Phys
5
6			mov	ecx, 64000/4
7			rep	movsd
8
9			ret
10Mcga_Flip		endp

64000/4 means ModeX, right?

No, it means 320x200, but not mode x in this case, as they use the plain old 13h mode. The /4 is only because they rep movsd, which move 4 bytes at a time. That means 64000/4 repitions.

Ah, right, overlooked the movsd. Crafty.

Hi everyone! And sorry for intrusion, also. I'm a bit late to the party, too. 😅

I'm not going to convolute this thread, I just wanted to say that 640x400 256c is a good starter indeed.
Games like the Höhlenwelt Saga used it, too.
And a few more games from the East or Korea, I think.

Mode 100h works on ancient VGA cards with 256KB, too, if a VBE TSR is loaded (tested with some OAKs and PVGAs).
I've uploaded a bunch if them here:
Re: OAK OTI-037c - 800x600 mode ?

Another advantage is that it is exactly double the size (h+v) of 320x200 and with the same aspect ratio.
Tools like DPaint can still be used for drawing a landscape etc.

The only downside is the non-square pixel ratio, I think.
8-Bit consoles Iike the NES had a lower resolution, but proper square pixels.
That made them look less pixelated than mode 13h.
So a lo-fi CRT monitor or a composite connection (VGA to AV) will make them look less artificial. 😉

By the way, that reminds me of my old HD cam corder.
It had a 1440x1080 resolution instead of 1920x1080, because it used the old CCD sensor technology (not CMOS).
Editing thus requires scaling to 1920x1080.

Anyway, good luck! 🙂👍
Jo22

Edit: Here's a small comparison of different resolutions on a VGA 19" CRT.
Re: Home Computer - was it a toy or a Personal Computer for the masses?

It's missing 640x400, though, because the attachments were limited to 5.
I'll take another one for you, if you like. 🙂

Honestly, I also like 640x400 very much. Has a neat memory size. As Jo22 said it can be used down to 256K VGA cards, has higher refresh rate, and is very similar to other 400 line modes (which includes 320x200, which is line doubled on VGA).

Unless the program was designed with square pixels in mind, I also prefer 640x400 over 640x480 as it is bit faster and keeps the aspect ratio that 320x200 uses while still looking hi-res.

root42 wrote on 2022-06-22, 14:35:

Honestly, I also like 640x400 very much. Has a neat memory size. As Jo22 said it can be used down to 256K VGA cards, has higher refresh rate, and is very similar to other 400 line modes (which includes 320x200, which is line doubled on VGA).

That's right, I often forget about this. 🙂
So mode 100h technically gives us 640x400 vs 320x400. That's a nice extra, I think.
And the 400 lines aren't line-double anymore, they can hold more details than before.

(Ok, to be fair, I admit some demoscene productions were technically able
to disable line-doubling somehow and use 400 lines in plain VGA before, but that was rather experimental in comparison to VBE, I guess. Maybe not all VGA compatibles supported that, also, not sure.)

I think I found the code for blitting blocks of changed screen data in LBA1:

https://github.com/2point21/lba1-classic/blob … S_PHYS.ASM#L225

It includes VESA bank switching. Maybe this can be an inspiration to you, @WhiteFalcon?

Jo22 wrote on 2022-06-22, 18:23:

That's right, I often forget about this. 🙂 So mode 100h technically gives us 640x400 vs 320x400. That's a nice extra, I think. A […]
Show full quote

root42 wrote on 2022-06-22, 14:35:

Honestly, I also like 640x400 very much. Has a neat memory size. As Jo22 said it can be used down to 256K VGA cards, has higher refresh rate, and is very similar to other 400 line modes (which includes 320x200, which is line doubled on VGA).

That's right, I often forget about this. 🙂
So mode 100h technically gives us 640x400 vs 320x400. That's a nice extra, I think.
And the 400 lines aren't line-double anymore, they can hold more details than before.

(Ok, to be fair, I admit some demoscene productions were technically able
to disable line-doubling somehow and use 400 lines in plain VGA before, but that was rather experimental in comparison to VBE, I guess. Maybe not all VGA compatibles supported that, also, not sure.)

Line doubling is a VGA CRTC register. It should work on ANY VGA card, back to IBM's 1987 original. It should always work, However it produced even WORSE pixel aspect ratio, so outside of demoscene productions it was rarely used. A few Fractal rendering programs used it to get "high res" 256 color graphics cheaply, IIRC. FractInt should support it.

Transport Tycoon doesn't really do anything special; it's a protected mode game (using a commercial but uncommon extender) and relies on the VGA card having vesa2/LFB support (it has univbe built-in to support older cards). It doesn't update at the max frame rate possible, usually hovering around 30-45fps even on overpowered machines.

@root42 Ah yes, I know. 😅 I just tried to be diplomatic here since I didn't mean to undermine
the usefulness of VBE, but at the same time didn't mean to be unfair to the VGA/CRTC artists.
Thanks for explaining it though, it's very good to understand the way you described it. 🙂👍
Edit: Changed size.
Edit: I'm in the background again; please everyone continue with your discussion. ^^

root42 wrote on 2022-06-22, 09:12:

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen: […]
Show full quote

Ok, I double checked, and for the 320x200 MCGA video mode they indeed rep movsd the whole FB to the screen:

Copy code to clipboard

1Mcga_Flip		proc	uses	esi edi
2
3			mov	esi, Log
4			mov	edi, Phys
5
6			mov	ecx, 64000/4
7			rep	movsd
8
9			ret
10Mcga_Flip		endp

is it because they opted for explicit MCGA support? 64KB MCGA doesnt have banks or chained modes (EGA compatibility) so there is no way of implementing hardware scrolling (offsets) or page flipping.

rasz_pl wrote on 2022-06-24, 09:47:

is it because they opted for explicit MCGA support? 64KB MCGA doesnt have banks or chained modes (EGA compatibility) so there is no way of implementing hardware scrolling (offsets) or page flipping.

I doubt it because MCGA was used only on VERY few and slow machines. They would have not been able to run LBA. I think they did it probably because the framebuffer was anyway in main memory so they had to blit quie a lot of data into VRAM anyway. Mode X would have complicated that as you needed to switch the bitplanes. It might have been just faster to do it in MCGA mode.

root42 wrote on 2022-06-23, 06:35:

I think I found the code for blitting blocks of changed screen data in LBA1:

https://github.com/2point21/lba1-classic/blob … S_PHYS.ASM#L225

It includes VESA bank switching. Maybe this can be an inspiration to you, @WhiteFalcon?

Sorry for the radio silence, unusually busy times at work. I will get to my old PC in about 10 days so will start slowly by verifying that I understand the VESA virtual screen principle correctly.
A few days of not seeing any ASM and it feels so foreign again 😜

LBA kind of lost my interest after I learned that they most probably run in PM. Like I messaged you, this I think is proof enough:

1Log = Malloc(640L*480L);	/* 307200L	*/

No way I could gram such a buffer in BorlandC, although I have heard that WatcomC does allow arrays larger than 64k. But I doubt they would just sacrifice half the conventional memory just for a double buffer.

jmarsh wrote on 2022-06-23, 15:37:

Transport Tycoon doesn't really do anything special; it's a protected mode game (using a commercial but uncommon extender) and relies on the VGA card having vesa2/LFB support (it has univbe built-in to support older cards). It doesn't update at the max frame rate possible, usually hovering around 30-45fps even on overpowered machines.

Interesting, okay, another game of of the question for learning about non-LFB uses.