Recent

Author Topic: Post Apocalyptic Petra, a small 3D platform game for MS-DOS (with sources)  (Read 11053 times)

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: Post Apocalyptic Petra, a small 3D platform game for MS-DOS (with sources)
« Reply #15 on: December 02, 2020, 12:18:02 pm »
Cool  :)
Conscience is the debugger of the mind

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Interesting game. But I have question about DOS version. Why haven't you tried to implement page flipping instead of copying? It's tricky thing, but it could improve performance.

Biggest problem - it really looks like knowledge about making games back then was some kind of secret. Because you can't find any information about that even in very detailed sources, like this one. So, yeah, we have many references, but zero programming guides. And all this references lack really important bit of information - VGA doesn't support mid-frame page flipping, like modern video cards do without vsync. I.e. vsync is actually required. And vsync is also very tricky thing, because some sources say, that you can't rely on IRQ2, and doing "wait for vsync" operation wastes too much time. It's really hard to find workaround for all that limitations. That's what making old games was about. It was real science.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

Bad Sector

  • Jr. Member
  • **
  • Posts: 69
    • Runtime Terror
Assuming page flipping is faster, it wont really make much of a difference - if any - since the performance bottleneck is on the rasterizer, followed by the renderer, followed by the sound mixer, etc. I also use copying on Windows with DirectDraw and when profiling the game on a Pentium 166 the copying part doesn't even register at the profile.

But also page flipping assumes unchained mode which in turn means non-linear memory layout. This would complicate the rasterizer significantly to the point where you'd be actually losing performance instead of gaining it.

Another thing to consider is bus speed: accessing the VGA memory is slower than accessing system memory. The game has both overdraw (meaning the same pixels -and thus memory regions- will be touched multiple times) and reads back from the framebuffer (for translucency effects). Doing everything in system memory and then copying the final frame to the VGA memory means that the VGA memory being slower wouldn't affect much.

Of course another (or really, the main) reason is that i wrote the simplest code to get stuff on screen since i had a ton more things to do :-P. But i did consider it later when optimizing the game, though it never ended up being a bottleneck and thinking about it made sense when considering how the memory is accessed.

FWIW DOS Quake also uses the copying method for VGA.

It could be usable for linear memory VESA modes on graphics cards with fast memory access but those are a can of worms i'd rather not bother with.
Kostas "Bad Sector" Michalopoulos
Runtime Terror

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
I always forget about that VRAM wait state. But anyway, copying 64K of data shouldn't be irrelevant. Of course it depends on optimization of other parts. I remember, that back in old times, when I was trying to make my own game for i286 12Mhz, copying video page was taking all free CPU cycles, not leaving anything for game logic.

Yeah, unchained mode is little bit harder, but it's about writing every 4th pixel and then repeating it for other 3 bit-planes.
« Last Edit: March 12, 2021, 05:38:05 pm by Mr.Madguy »
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

 

TinyPortal © 2005-2018