Shop OBEX P1 Docs P2 Docs Learn Events
90's style 3D (Now with USB keyboard scancodes) - Page 2 — Parallax Forums

90's style 3D (Now with USB keyboard scancodes)



  • You could dither.
  • RaymanRayman Posts: 13,855
    I just did it in photoshop to check...
    Result is just OK. If the tiles went from 64x64 to 128x128 would be better...
    64 x 64 - 5K
  • Check out what Quake did with 256 color VGA.

    They used 16 colors, with 16 levels of brightness. (Dark to Bright)

    0: Black/White x 16 shades
    1: Brown x 16 Shades
    2: Light Blue x 16 Shades.

  • Yeah, that is about the limit of it. Helps to have a blurry TV.

    Only other thing I can think of gets complex. Run higher bit depth scanline buffers and use a shift and lookup table to convert the 8 bit pixels to their light value higher bit depth values on the fly.

    Without either limiting colors, or dither, or a bigger buffer, dynamic display seems like the answer.
  • RaymanRayman Posts: 13,855
    edited 2018-12-10 20:00
    Just got my frame rate back to ~10 fps (from 8 fps), but not fully clear why...
    Except, looks like you can't jmp into a hubexec call...

    I turned some code (updateScreen) into a subroutine to move outside of cog for hubexec.
    Then, I brought it back into cog.
    Anyway, I just noticed this jmp in front of the RET and commented it out:

    Funny thing is that the jmp should have the same effect as RET because the caller just jumps to the same place.

    But, "DrawBackground" is now a hubexec routine. It must be that the RET in DrawBackground in hubexec mode goes to a different place if jumped to rather than called...

    Wait, I think I get it now... I was doing DrawBackground twice...
  • 332 is 4 shades of gray (including black). I just picked on Blue because our eyes are least sensitive, but using a packed color mode gives you the simplest linear color conversion. Unless you want to implement HSV colorspace and spread the bits out appropriately.
  • The P2 has a nice LUT for proper 8-bit indexed color, doesn't it? No need for garish 332.

    P2 could run DOOM, I think. Main problem is RAM: DOS doom needs some 4 MB - however, that includes all sorts of stuff (I don't think it uses the first 640k at all), so by simplifying the levels a little (like on the console ports of the day) and streaming the sound effects from SD card, it should work out fairly well. I'd use one cog for running the game logic, one for sound, one for SD card handling, one for TV output, two for rendering.
  • RaymanRayman Posts: 13,855
    Thinking about this again...
    Say we want several wall tiles and the ability to darken them.
    But, we also want colors for floor and especially background...

    Think I'd make an image with all the wall tiles and darkened versions of them.
    Then, I'd have Photoshop pick the best palette using 128 colors.

    Then, do the same with just floor tiles and background.

    Then, combine those two palettes.

    Finally, create darkening look up tables for wall tiles. Just a 128 entry byte table...
  • potatoheadpotatohead Posts: 10,253
    edited 2018-12-10 21:04
    That will work. But will be super coarse and changing, if lighting changes.

    That is how ID worked with 8 bit LUT graphics. The palette changes dynamically.
  • Use the Quake palette, and fit your images to it. Then you don't need lookup tables.
  • This tool will help:

    Also, this thread covers another way that is more involved to setup, but gives better results:
  • Spiffy!

    Now, when does my eval board arrive? Lol.
  • RaymanRayman Posts: 13,855
    Looks like the "COLORMAP" in doom is how they did shading. It's similar to the look up table scheme I was thinking of...
    But, I see they also dynamically changed the palette to ones that were redder or yellower.
    The redder one used when player is damaged. (I think I remember seeing that!).
  • RaymanRayman Posts: 13,855
    I was looking at using QROTATE instead of sine and cosine tables in the floorcast section of code.
    Was disappointed to see that this was actually slower...
  • When you used QROTATE, did you put instructions between the issuing of the QROTATE and reading the result? There is a stall there if you don't.
  • floorcasting doesn't need any sines, anyways. Just some vector*matrix multiplications, except that when doing it in columns, one of the scalars is constant and the other comes from a LUT, indexed by Y position. Thus, only two two multiplies and additions are required. (Does the P2 have an FMA instruction?) When doing it in rows, the constant scalar comes from a LUT (or is calculated, allowing for vertical camera movement) and the other one is a linear function of the X position, so there's only 2 additions per pixel.
  • RaymanRayman Posts: 13,855
    Well, I was able to move sin&cos outside of the inner, vertical loop.
    Still need it for the column loop though...
    Although, LUTs could help. Have one already but if had more memory, could speed it up...
  • A horizontal loop should be a bit faster, still.
  • RaymanRayman Posts: 13,855
    Frame rate up to 12 fps. Still with just 1 cog.

    Most code fits in that cog, but had to move some out to hubexec space.
    Added in two darker versions of wall tile to make far walls a hair darker.
    New binary in first post.
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Frame rate up to 12 fps. Still with just 1 cog.

    Most code fits in that cog, but had to move some out to hubexec space.
    Added in two darker versions of wall tile to make far walls a hair darker.
    New binary in first post.

    This is on the FPGA at 80MHz, right?
  • RaymanRayman Posts: 13,855
    Yes, still waiting for evaluation board.
    Two weeks until chipmas
  • RaymanRayman Posts: 13,855
    edited 2018-12-12 17:50
    I think I've decided that the trig table use could be improved for P2...

    Right now, it takes up 60kB of space to cover angles from 0..360.
    Think we can trim that down to 0..90 and save 1/4 of space with penalty of only a few clocks of extra instructions.

    Also, the example has tables of sin, cos, tan and 1/sin, 1/cos, 1/tan.
    It doesn't look to me like these "inverse" tables are not really needed as qdiv looks to be same speed as qmul.

    Also, think I've decided that Q16.16 is OK for tan table, but sin and cos should be more like Q1.31...
  • The sin table on P1 is 0..90 degrees, too.
  • RaymanRayman Posts: 13,855
    I've been thinking about what might be possible here, with the constraint that everything has to fit in 512kB...

    The old DOS games required 8 MB, so this is a real limitation...

    Anyway, I think ROTT (Rise of the Triad) is about the level of sophistication that is fairly easy to do. ROTT uses the Wolf3d engine with some tricks that make it feel like real 3D.

    The next level is the DOOM engine. I took a look at it and it looks way to complex to ever fit in 512kB...

    Anyway, I just forced myself to play ROTT to refresh my memory and I see it's pretty cool, like I remember, but not so different from the simple example I'm doing here...
  • I'm thinking the rendering code itself cannot be that large.
    But we do need some kind of external RAM solution that we can all consistently use for texture or geometry data.
  • Yes, RAM use is going to be key for P2 with 3d graphics and/or gaming. Write contention and latency are probably going to be the major issues to deal with once external RAM is added. Perhaps even using multiple independent RAM blocks for different things may be of benefit if the pin count remains manageable, allowing multiple processes to simultaneously access RAM or for double buffers etc.
  • ElectrodudeElectrodude Posts: 1,621
    edited 2018-12-14 05:18
    rogloh wrote: »
    multiple processes to simultaneously access RAM or for double buffers etc.
    An external-RAM eggbeater. Have multiple cogs take turns with external RAMs in a predetermined way.
  • How much can be pulled directly from the SD card?
    Could Procedurally Generated levels/textures help here?

    I'm not sure what you have in memory for the levels right now. Level descriptions and textures I'm assuming. Could off screen textures be cached in the SD?

  • roglohrogloh Posts: 5,151
    edited 2018-12-14 07:23
    An external-RAM eggbeater. Have multiple cogs take turns with external RAMs in a predetermined way.

    Well I guess that was what I was thinking, not sure if I'd call it exactly that though. :confused: I was thinking one COG could have exclusive use of one block of RAM, and another COG another type of RAM (on different pins), both simultaneously, instead of competing for some shared access of a common external RAM. For example, you could have one RAM being read by a video renderer process and another being written into for the next frame, or being accessed for textures etc. Also having more than one block of RAM obviously burns more pins. Maybe HyperRAM is good for that in some cases, if the overall latency is still acceptable.
Sign In or Register to comment.