Jump to content
IGNORED

Raycaster


Asmusr

Recommended Posts

On 10/14/2020 at 12:13 AM, artrag said:

How do you deal with transparent pixels?

The check is part of the unrolled code. For the biggest size (192) it looks like this:

sprite_c0:
       equ  $
!      movb *r0+,r13
       jeq  !
       szcb r9,*r1
       socb r13,*r1+
       szcb r9,*r1
       socb r13,*r1+
       szcb r9,*r1
       socb r13,*r1+
       jmp  !!
!      ai   r1,3
!      movb *r0+,r13
       jeq  !
       szcb r9,*r1
       socb r13,*r1+
       szcb r9,*r1
       socb r13,*r1+
       szcb r9,*r1
       socb r13,*r1+
       jmp  !!
!      ai   r1,3

At this size it's reading one texture byte for every three screen bytes written, so the overhead of the check is relatively low.

  • Like 1
Link to comment
Share on other sites

On 10/13/2020 at 11:14 PM, arcadeshopper said:

just wish the ceiling would move when you move.. even if its just flipping 2 images maybe.. 

Right now there are 8 different images (one for each direction). One option would be to make the floor/ceiling tiles twice as big and increase the number of images to 32 (8 for each of the 4 positions within the bigger tiles).

  • Like 1
Link to comment
Share on other sites

Right now there are 8 different images (one for each direction). One option would be to make the floor/ceiling tiles twice as big and increase the number of images to 32 (8 for each of the 4 positions within the bigger tiles).
Nod wonder if you just swapped the colors each step

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

6 hours ago, arcadeshopper said:

Nod wonder if you just swapped the colors each step

Sent from my LM-V600 using Tapatalk
 

Using a symmetric checkered texture you would only need 16 different images. But the floor and ceiling would have to be redrawn every frame, which would affect performance.

Edited by Asmusr
  • Like 1
Link to comment
Share on other sites

Having an animated floor/ceiling would reduce the frame rate almost down to how it is now when you turn and the entire screen is redrawn. But maybe a steady frame rate would be preferable to the speed-ups you experience when running through corridors if you got an animated floor/ceiling as a bonus? Removing some of the optimizations from the code would certainly make it easier to understand and maintain.

  • Like 1
Link to comment
Share on other sites

In that case I vote for having free movements on any angle and speed ?

 

PS

Would it be possible to jump into the middle of the unrolled code to skip a run of transparent pixels?

Encoding offsets into the column data and scaling them to jump into the proper point of the unrolled code could cost less than processing the transparent pixels one by one

Link to comment
Share on other sites

10 hours ago, artrag said:

In that case I vote for having free movements on any angle and speed ?

 

I'm not sure if you're suggesting anything or just joking.

10 hours ago, artrag said:

Would it be possible to jump into the middle of the unrolled code to skip a run of transparent pixels?

 

Maybe, but it sounds like a lot of trouble for a rather limited improvement of speed.

Link to comment
Share on other sites

 

The video I have linked above is a commentary on the Wolfstain 3D sources and seems to say that ID software has used a trick for rendering zoomed sprites about precomputed offsets for run of pixels...

I will try to investigate more.

 

Btw

How many scales do you deal with when you zoom sprites and walls?

Link to comment
Share on other sites

14 minutes ago, artrag said:

96×32 is the size of the table you could use to store offsets within the unrolled code for spite scaling (assuming textures are 32 pixels height).

Only I have no idea about the size of each entry of the table ?

The textures are currently 32x64, but reducing the height to 32 would in itself reduce the overhead for handling empty pixels by a factor 2 for heights where you need to read all the texture pixels, i.e. >= 32.

Link to comment
Share on other sites

Only you can evaluate the trade off

I can't say if it is worth trying to avoid the test on trasparent pixels

 

The idea should be to segment the columns  of sprites in runs of non trasparent pixels

Each run has a lenght and a base offset in the texture scale (from 0 to 63 if textures are 32x64)

 

When you plot a run of pixels at a given scale

- you choose the unrolled code corresponding at the proper scale 

- you use the texture lenght and the scale to enter in the unrolled code at a proper entry point in order to plot the correct numer of pixels (scale x run lenght)

- you initialize the registers used by the unrolled code according to offset and scale in order to make the code plot at the correct starting point in the screen column (starting point = run offest x scale)

 

You can avoid any testing on transparet pixels and reuse unrolled code for scaling walls 

 

 

Anyway you do just 64 tests if scale >1 so really I can't say what is best

 

Edited by artrag
Link to comment
Share on other sites

4 hours ago, artrag said:

Only you can evaluate the trade off

I can't say if it is worth trying to avoid the test on trasparent pixels

 

The idea should be to segment the columns  of sprites in runs of non trasparent pixels

Each run has a lenght and a base offset in the texture scale (from 0 to 63 if textures are 32x64)

 

When you plot a run of pixels at a given scale

- you choose the unrolled code corresponding at the proper scale 

- you use the texture lenght and the scale to enter in the unrolled code at a proper entry point in order to plot the correct numer of pixels (scale x run lenght)

- you initialize the registers used by the unrolled code according to offset and scale in order to make the code plot at the correct starting point in the screen column (starting point = run offest x scale)

 

You can avoid any testing on transparet pixels and reuse unrolled code for scaling walls 

 

Unfortunately it cannot be the same code as for the walls because it takes one instruction to draw a wall pixel but two to draw a sprite pixel. On the other hand the sprite code is the same for even and odd columns.

Are you suggesting to encode this once per texture or once per texture and scale? If it's once per texture it appears to require some quite complex calculations to decide where to call the code and what the source and destination addresses should be set to. If it's once texture and scale it appears to require a lot of space (something like 32K per texture). 

 

Link to comment
Share on other sites

On 10/13/2020 at 11:14 PM, arcadeshopper said:

just wish the ceiling would move when you move.. even if its just flipping 2 images maybe.. 

I did it, and I think the result is worth the reduced frame rate in some places.

 

 

The floor/ceiling now takes up half of the 512K ROM, but it could be compressed and uncompressed to SAMS.

texcaster.rpk texcaster8.bin

  • Like 10
Link to comment
Share on other sites

1 hour ago, fabrice montupet said:

Absolutely great!

Do you think that in a future development , arming will be more oriented medieval, like arrows and swords?

It was my plan to do something medieval and dungeon like, but since the color palette makes that difficult my current plan is to do something 'abandoned tech'/sewer like. The current selection of monsters doesn't really comply with that, so if I don't want to draw them I need to look for a another source. The current weapon you could think of as a thrown rock, which should apply to any setting, but really the whole thing is up for debate - also the way of controlling the game, which could be changed to 'mouse pointer' style. Maybe I should reserve some screen space for status information, and maybe the game should be turn based? The only thing that's clear is that this is not a first person shooter but more like an RPG. I'm not going to update the non-textured FPS any further.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Asmusr said:

I did it, and I think the result is worth the reduced frame rate in some places.

 

 

The floor/ceiling now takes up half of the 512K ROM, but it could be compressed and uncompressed to SAMS.

texcaster.rpk 53.31 kB · 3 downloads texcaster8.bin 512 kB · 4 downloads

much better on my brain, and still damn fast!

 

Greg

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...