Image Map Image Map
Page 1 of 5 12345 LastLast
Results 1 to 10 of 45

Thread: Possible to do texture mapped pseudo 3D rendering on a 8088 / CGA machine?

  1. #1

    Default Possible to do texture mapped pseudo 3D rendering on a 8088 / CGA machine?

    Over the years I've developed several pseudo 3D renderers similar to Wolfenstein 3D for various bits of hardware. Most recently Catacombs Of The Damned! for the Arduboy which runs on an Atmega chip with only 2.5KB of RAM. I also developed a demo for the Uzebox, another microcontroller based console which works without a framebuffer and generates a composite signal on the fly in software.

    I recently acquired a Sharp PC-3000 which is an XT compatible DOS based palmtop computer (although higher clocked) and was considering the possibility of writing a 3D renderer for it. I was hoping to pick the brains of those who are familiar with the XT class hardware!

    For a high level overview of what I was considering:
    • The 3D effect will be built using vertical 'slices' similar to Wolf3D. Could use raycasting, BSP or portals to build a 1-D array which stores for each screen column, the scale of the wall and which slice of texture to use.
    • Each slice can then be rendered by using a 'coded scaler', similar to Wolf3D (it is described in detail in Fabien Sanglard's Wolfenstein Black Book) Essentially, at load time, you generate a set of specialised functions for rendering wall slices at different sizes in an unrolled loop, so that you can avoid calculating the scaling at run time.
    • Sprites are drawn in a similar way to walls by rendering slices with scaler functions, but with some changes to handle transparency.


    It certainly looks like it could be too much for such a limited system, so here are some of my thoughts of corner cutting:
    • The first easy win: render the 3D portion in a smaller window at e.g. 256x128 (which works out to about 50% of the framebuffer pixels) with the rest of the screen having a nice border, status bar etc
    • The renderer could be set up to support both 320x200 4 colour and 160x200 composite colour modes. In the 4 colour RGB mode, use vertical stripe / dither patterns to fake extra colours. Effectively render at 160x200 in both modes. With the reduced size window this is actually 128x128 logical size.
    • Rendering at this resolution means that instead of 2 bits per pixel, it is effectively like rendering at 4 bits per pixel / one nybble per pixel. This still complicates all the rendering functions somewhat: to write a pixel, you have to first read the relevant byte, mask it, shift your value, OR it, write it back. Since the CGA card only has enough VRAM to store one framebuffer, for a renderer like this you would need to store a buffer in main RAM and then copy the contents to VRAM once you have finished. It then struck me: the buffer in main RAM could be stored at 1 byte per pixel (which works out to 16K with the 256x128 window), and the routine that blits to VRAM could be a big unrolled loop which squashes it back down into the 4 bits per pixel format as it writes to VRAM. With some special care, the scaling routines could output either the high or low nybble depending on if it is an even or odd column, so the inner loop of the blit routine could be as simple as 2 word reads, 2 OR instructions, and one word write.
    • If the texture maps are simplified, e.g. all walls have a very basic brick pattern, then the texture details themselves can be coded right into the wall scaler functions so texture details don't have to be loaded from RAM.


    Does anyone with experience with the real hardware think that this would all be possible to do at an interactive framerate? Any obvious shortfalls or better ways of approaching the above?

  2. #2

    Default

    I would look at the 'hacked' text modes that give you 16 color lo-res graphics. Lowering the resolution is going to improve your frame rate by simply reducing the amount of pixels you have to render. You can get 160x100 in 16 colors, but to run well on a stock IBM-PC, you might even consider 80x50. You wouldn't need to worry about screen snow at the 80x50 resolution, get double buffering and you can get acceptable quality at a high enough frame rate to be fun.

    Here is my 2.5 D raycaster on a 1 MHz Apple II at 40x48 resolution in 16 colors at around 20-25 fps: https://www.youtube.com/watch?v=QUN5CSWiLaw&t=3s

    I think you could pull this off at a slightly higher resolution on a 4.77 MHz 8088.

  3. #3

    Default

    Certainly possible, especially if you're willing to compromise on resolution. resman's idea about using text mode is a good one; in particular, I'd go for the 80x50 approach, since that means each color/attribute byte corresponds to two pixels in the same column, so there's no need to worry about masking/shifting/etc. and the whole thing becomes much simpler, especially since framebuffer access would no longer need to be a read-modify-write process.
    Last edited by commodorejohn; July 13th, 2020 at 04:43 PM.
    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

  4. #4

    Default

    Come think, if you wanted to get super fancy, you could use one of the hacked text modes to get 8x4 or 8x2 character cells (80x50 or 80x100) and use the halftone characters in code page 437 to blend between two colors for a total of...um, 376 "colors"
    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

  5. #5

    Default

    Thanks for the feedback! @resman your raycaster is really impressive!

    I wrote a test which did the most basic wall scaler (just solid colour) and the combine+blit to screen routine that I described. On my Sharp PC3K (clocked at 10MHz) it takes ~46ms for the scaler to fill the screen and ~86ms to do the blit. This only reaches ~7FPS which isn't very promising since it isn't even doing the actual wall calculations yet!

    I initially considered text mode sort of 'cheating' but after some consideration it might be the best option. Having enough VRAM available to do page flipping and writing directly to VRAM would be the biggest win I think.

  6. #6

    Default

    If only there were a full-screen CGA mode with linear memory addressing, 256 colours (one byte per pixel), and two pages so you could display one while rendering the other. Even though the resolution would have to be very low (like 80x100) in order to fit two pages into 16kB, it would be ideal for this sort of thing!

    That reminds me - there's a project that I started and really should finish...

  7. #7

    Default

    I put together a simple tech demo to see what a renderer using CGA text mode would look like. I get ~20FPS on my Sharp PC 3000 and HP 100LX although I will probably need to change the colours to work better on the LCD screen. There is nothing to stop CGA snow which might be a problem on a real CGA card.

    Here is a video clip from DosBox-X

  8. #8

    Default

    Quote Originally Posted by jhhoward View Post
    I put together a simple tech demo to see what a renderer using CGA text mode would look like. I get ~20FPS on my Sharp PC 3000 and HP 100LX although I will probably need to change the colours to work better on the LCD screen. There is nothing to stop CGA snow which might be a problem on a real CGA card.

    Here is a video clip from DosBox-X
    That looks pretty good! At that resolution you could use the 40-column text mode instead of the 80-column one, the vertical half character instead of the horizontal half, and reprogram the CRTC to give you 50 rows instead of 25. That would solve the snow problem, though it would be more difficult to write the HEALTH/MANA/SCORE labels.

  9. #9

    Default

    Not at all bad for a start!
    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

  10. #10

    Default

    Quote Originally Posted by reenigne View Post
    That looks pretty good! At that resolution you could use the 40-column text mode instead of the 80-column one, the vertical half character instead of the horizontal half, and reprogram the CRTC to give you 50 rows instead of 25. That would solve the snow problem, though it would be more difficult to write the HEALTH/MANA/SCORE labels.
    Does CGA snow only happen when in 80 column mode? I thought it was a general text mode issue. The only problem with using vertical half characters is it would complicate the rendering functions as everything is rendered in vertical spans.

Tags for this Thread

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
  •