Image Map Image Map
Page 2 of 6 FirstFirst 123456 LastLast
Results 11 to 20 of 52

Thread: Little Game Engine for MS DOS.

  1. #11
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,730
    Blog Entries
    1

    Default

    [QUOTE=Mills32;545615]
    And the last reason... To avoid all of this, you have to draw everything to a VRAM page, and use double buffering etc... That will kill the 8088 and 8086 .
    Writing to visible or hidden RAM is the same speed. And it can be *faster*, not slower, since you can take advantage of double-buffering to not worry about where the beam is on the screen (don't have to wait for retrace), or erasing things "gracefully" (since they're hidden).

    The advantages of mode-x:
    - Playfields larger than the screen means you can have a 320x240 full-page scrolling experience, no need to try to "hide" borders or come up with non-standard video modes that are not compatible with all monitors/cards/emulators.
    - VRAM copying can be faster than system-ram-to-vram copying (if you have slow video cards, and can fit everything you need in 128KB of VRAM or so).
    - Hardware split-screen, if you want/need it
    - If you need it, fast filling/clearing (turn on all planes, then writing one byte actually writes four)

    I'm not trying to force you to support it, just making sure you understand that the advantages outweigh the disadvantages. But saying it would be "slower" on 8088 is simply not true, in fact the VRAM copying exceeds the speed of an 8088 CPU trying to do the same. For larger areas (16x16 and bigger) it is definitely way faster to do a VRAM copy on an 8088 system.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  2. #12
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,730
    Blog Entries
    1

    Default

    Ultimately, this is the most compelling reason for supporting mode-x: What you're doing doesn't work on all hardware:



    This is a very standard Paradise PVGA1A chipset.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  3. #13

    Default

    Quote Originally Posted by Trixter View Post
    Ultimately, this is the most compelling reason for supporting mode-x: What you're doing doesn't work on all hardware:
    Wow.. So PCem is working OK, it just does the same!.

    I know why this happens... the VGA does not wrap the VRAM around 64 kb, if you scroll down all the 4 pages (256 Kb) it will show pixel data again...

    Oh and the "snow" is because I change the palette outside vblank .

    So this might work on a real MCGA, but not on VGA. It works well on SVGA and on modern GPU'S for some reason.

    Ok, I first have to check if the wrapping issue can be solved by changing some register or something.

    If that can't be solved, I'm going to do it with mode x , we just have to live with limited vertical scrolling, so that I can store tiles and sprites at the bottom of the vram, and also can use the split screen to draw a window with info.

    But there is a problem, how do I port the sprite drawing with transparency to mode x?, that's going to be a bit complex.
    Last edited by Mills32; November 25th, 2018 at 01:13 AM.

  4. #14

    Default

    I tried out the mario demo on a few of my computers and unfortunately I agree it isn't very compatible.

    8088 10 MHz:
    Oak OTI067 (512K) - only card that worked 100% - scrolls pretty smooth, some sprite flicker
    ATI VGA Wonder XL (1MB) - hangs before loading screen
    ATI VGA Wonder 1024 (1MB) - doesn't hang but no graphics (just blinking cursor in text mode), can see the palette fade when it's loaded

    386SX 25 Mhz:
    Cirrus Logic GD5410 (256K) - large amounts of graphics corruption, jerky scrolling
    Cirrus Logic GD5429 (1MB) - small amount of graphics corruption, scrolls smooth

    Pentium 75 MHz:
    Cirrus Logic GD5440 (2MB) - very minor graphics corruption, scrolls smooth, randomly hangs during game

  5. #15

    Default

    Quote Originally Posted by Plasma View Post
    I tried out the mario demo on a few of my computers and unfortunately I agree it isn't very compatible.

    8088 10 MHz:
    Oak OTI067 (512K) - only card that worked 100% - scrolls pretty smooth, some sprite flicker
    ATI VGA Wonder XL (1MB) - hangs before loading screen
    ATI VGA Wonder 1024 (1MB) - doesn't hang but no graphics (just blinking cursor in text mode), can see the palette fade when it's loaded

    386SX 25 Mhz:
    Cirrus Logic GD5410 (256K) - large amounts of graphics corruption, jerky scrolling
    Cirrus Logic GD5429 (1MB) - small amount of graphics corruption, scrolls smooth

    Pentium 75 MHz:
    Cirrus Logic GD5440 (2MB) - very minor graphics corruption, scrolls smooth, randomly hangs during game
    Thank you very much for testing. I like that the 8088 runs the Mario demo smooth.

    I guess it's mode x time .

    About the sprites in mode x, I found this in another forum: "If you want efficient mode X sprites, I suggest taking a cue from how DOOM does it's sprites. Encode them as a series of vertical run-length strips, so that your code can minimize the number of I/O writes needed to switch which VGA plane (one of 4 pixels) it's writing to and maximize sprite output."

    That will be fast enough i hope.
    Last edited by Mills32; November 25th, 2018 at 03:41 AM.

  6. #16

    Default

    Yes, that's good advice. You should also consider interleaving the columns so that you can write all the data for each bitplane in one go.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  7. #17
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,730
    Blog Entries
    1

    Default

    Quote Originally Posted by Mills32 View Post
    Wow.. So PCem is working OK, it just does the same!.
    But notice there is also very jerky horizontal scrolling on real hardware.

    Quote Originally Posted by Mills32 View Post
    But there is a problem, how do I port the sprite drawing with transparency to mode x?, that's going to be a bit complex.
    Why reinvent the wheel? Just use XLIB. They solved these problems 25 years ago and the code is in C (there's a port to TP called XLIBPAS) so you should be able to just drop it in.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  8. #18

    Default

    Quote Originally Posted by Trixter View Post
    But notice there is also very jerky horizontal scrolling on real hardware.
    Yes that's something wrong in my code, i'm doing the scroll outside the vblank, (like the snow problem when fade in/out), PCem also shows it, I should forget Dosbox when I test .

    Quote Originally Posted by Trixter View Post
    why reinvent the wheel? Just use XLIB. They solved these problems 25 years ago and the code is in C (there's a port to TP called XLIBPAS) so you should be able to just drop it in.
    I downloaded xlib some time ago, but I had not tested it yet. I just read some source files and I saw it "compiles" the sprites. Does that mean the program won't be able to load bmp files at run time? and the images are compiled with the source?.

    Thanks again for testing.

  9. #19
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,730
    Blog Entries
    1

    Default

    Quote Originally Posted by Mills32 View Post
    Yes that's something wrong in my code, i'm doing the scroll outside the vblank, (like the snow problem when fade in/out), PCem also shows it, I should forget Dosbox when I test .
    IIRC with mode-x the address start is latched, so you don't have to wait for retrace for that stuff.

    I downloaded xlib some time ago, but I had not tested it yet. I just read some source files and I saw it "compiles" the sprites. Does that mean the program won't be able to load bmp files at run time? and the images are compiled with the source?.
    You should read it more thoroughly. XLIB has three methods for handling sprites:
    - Rearrange the data into a planar organization so that you only have to switch write planes 4 times.
    - "compile" the sprites which turns them into executable code that plots them. This makes them bigger, but if you have large sprites with large transparent areas, makes them faster.
    - Store them in VRAM so that VRAM-to-VRAM copies are possible.

    It comes with the programs to rearrange/compile graphics data so you don't need to write that part.

    Try the demo program that comes with it, run that to see what it can do and how fast.
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Documentation and original disks for: Panasonic Sr. Partner, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  10. #20

    Default

    It looks like the xlib compiled sprites are incredibly fast, a 30x30 sprite started to run slow at 92 cycles on dosbox, (while my little engine sprites were way slower).

    The good thing is the engine should work faster in mode-x (without the double buffering), and will be a lot more compatible .

    I'll have to say goodbye to the MCGA, anyway MCGA is not very common.

    But first I have to check if the compiled sprites are using a lot of 286 instructions, (I hope not).

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •