artrag Posted October 13, 2020 Share Posted October 13, 2020 2 Quote Link to comment Share on other sites More sharing options...
artrag Posted October 13, 2020 Share Posted October 13, 2020 An interesting video... 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 13, 2020 Author Share Posted October 13, 2020 I have optimized the sprite drawing in the same way as for the walls. The number of instructions per pixel has dropped from 8-9 to 2-5. texcaster.rpk texcaster8.bin 11 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 13, 2020 Share Posted October 13, 2020 just wish the ceiling would move when you move.. even if its just flipping 2 images maybe.. 2 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted October 13, 2020 Share Posted October 13, 2020 How many frames per second do you get in the worst case? It seems pretty smooth even when sprites are close to the player. How do you deal with transparent pixels? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2020 Author Share Posted October 15, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2020 Author Share Posted October 15, 2020 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). 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 15, 2020 Share Posted October 15, 2020 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 stepSent from my LM-V600 using Tapatalk Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2020 Author Share Posted October 15, 2020 (edited) 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 October 15, 2020 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 15, 2020 Author Share Posted October 15, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted October 15, 2020 Share Posted October 15, 2020 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 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 16, 2020 Author Share Posted October 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
artrag Posted October 16, 2020 Share Posted October 16, 2020 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? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 16, 2020 Author Share Posted October 16, 2020 1 hour ago, artrag said: How many scales do you deal with when you zoom sprites and walls? 96 for sprites and 138 for walls. Quote Link to comment Share on other sites More sharing options...
artrag Posted October 16, 2020 Share Posted October 16, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 16, 2020 Author Share Posted October 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
artrag Posted October 17, 2020 Share Posted October 17, 2020 (edited) 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 October 17, 2020 by artrag Quote Link to comment Share on other sites More sharing options...
artrag Posted October 17, 2020 Share Posted October 17, 2020 (edited) PS https://github.com/id-Software/wolf3d This should be the raycasting https://github.com/id-Software/wolf3d/blob/master/WOLFSRC/WL_DRAW.C Edited October 17, 2020 by artrag Quote Link to comment Share on other sites More sharing options...
CrazyChris Posted October 17, 2020 Share Posted October 17, 2020 Phenomenal! Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 17, 2020 Author Share Posted October 17, 2020 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). Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 17, 2020 Author Share Posted October 17, 2020 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 10 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted October 17, 2020 Share Posted October 17, 2020 Absolutely great! Do you think that in a future development , arming will be more oriented medieval, like arrows and swords? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 17, 2020 Author Share Posted October 17, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 17, 2020 Share Posted October 17, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
oddemann Posted October 17, 2020 Share Posted October 17, 2020 Impressing what your able to squish out of a "rock" Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.