Asmusr Posted September 10, 2020 Author Share Posted September 10, 2020 24 minutes ago, MueThor said: Now some stupid questions: You write that the resolution is 64x192. Not 192x64 (the images in your videos are broader in comparison to their height)? And will the Raycaster be really much slower, if you worked with a resolution of 128x192? Yes 64x192, with fat pixels that are 4x1 normal pixels. This is the highest resolution where you can set the color of each pixel independently. To work with a resolution of 128x192 you would have to cast twice as many rays, upload twice as much data to the VDP, and spend a lot more time drawing each pixel. Do you know the limitations of the 9918A bitmap mode, that you can only have 2 colors per 8x1 pixels? You would have to keep track of that and decide which colors to use. When you draw in this mode by hand you can arrange your drawing in clever ways to work around this restriction, but in the raycaster the program would have to make quick decisions, and the result might not look better that what we have now. 1 Quote Link to comment Share on other sites More sharing options...
LASooner Posted September 11, 2020 Share Posted September 11, 2020 Holy s***, man this amazing work. The icon for our latest game takes up more memory than what you're working with. Sent from my Pixel XL using Tapatalk 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted September 12, 2020 Share Posted September 12, 2020 (edited) On 9/10/2020 at 9:43 AM, MueThor said: Now some stupid questions: You write that the resolution is 64x192. Not 192x64 (the images in your videos are broader in comparison to their height)? And will the Raycaster be really much slower, if you worked with a resolution of 128x192? The problem is if he has to go higher than 64 horizontal resolution, he'll have to update the pattern table. It's hard to update both the color table and pattern table at the same time because there's about 12KB of data to update and the graphic chip isn't very fast. Then there's possiblity running into attribute color clash issue. This method only update the color table while the pattern table stay static is probably the best and fastest method of doing a raycaster engine on this graphic chip. Every cell of pattern table is probably filled with 00001111. This is awesome to see how this is coming along. Something like Faceball 2000 would be possible using this engine. Edited September 12, 2020 by Kiwi 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 18, 2020 Author Share Posted September 18, 2020 (edited) Now the eye is there, so I just need to add the beholder. ? From now on SAMS is required to see all the textures. If you only have 32K you better like treasure chests, because there will be a lot of them.? The main new thing is of course the objects (eyes, chests), and most of the features are now working as in the non-textured version. The object drawing is slow because no cheating is involved. It's scaling and drawing the textures in real time. And it also has to support transparency, which makes it difficult to optimize in the same way as the walls, because the unrolled code would have to depend on the textures. Maybe if the textures were not allowed to have interior transparent sections, like the weird 'grating boss' I'm shooting at the end of the video, it would be possible to optimize? @artrag will probably know what to do. I think my next step will be to move into the dungeon: draw a new map and darker, dungeon-like textures (9918A colors makes that very hard). I'm considering if changing the texture size from 16x64 to 32x64 would make any difference? They still have to be displayed in the same 64x192 mode, but it could be worth it for the close-ups. On the other hand, small details would may be missed at long range. The exciting thing about this project is that for once I'm not bound by the number of sprites in a row or the number of patterns in the pattern table. I can add hundreds of textures to SAMS without running out of space. texcaster.rpk texcaster8.bin Edited September 18, 2020 by Asmusr 14 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 18, 2020 Share Posted September 18, 2020 Looking really sharp, and great speed. For the sprites, I know some systems like the Apple sometimes used compiled sprites - rather than copying a texture they used code to draw the object directly. Not sure off the top of my head how you'd put scaling into that, but with that concept transparency isn't a concern - that's just part you don't draw. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 19, 2020 Share Posted September 19, 2020 I suddenly had flashbacks to Corridor 7 !!! Viewing recent videos was certainly a 'wow' event. When I last had a chance to check out the topic, it seemed there was more freedom of movement. Is that still doable with the current raycaster or is it now locked to 8 directions due to calculations and speed. 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 19, 2020 Share Posted September 19, 2020 It'll be nice to finally use my SAMS. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 19, 2020 Author Share Posted September 19, 2020 5 hours ago, InsaneMultitasker said: Viewing recent videos was certainly a 'wow' event. When I last had a chance to check out the topic, it seemed there was more freedom of movement. Is that still doable with the current raycaster or is it now locked to 8 directions due to calculations and speed. It only works to use a fixed image for floor/ceiling when you move one square at a time. 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 19, 2020 Share Posted September 19, 2020 (edited) Greetings for the update, now with the sprites in place it is even more impressive! Actually having only convex sprites could maybe lead to optimized code close to the one used for columns. But managing different starting points on the screen and different column size would be complex. With the same restriction, once you have supported SAMS, it could be less stressful (and slightly faster) to store each sprite frame already scaled for all distances. It will make the storage for sprites explode but you should have plenty of room to accommodate it even if you decide to render sprites under 8 view angles. All scaling of the sprite frames can be scripted offline. Honestly I didn't do that in my demos because the way the VDP works on msx2 (in parallel to the cpu) makes software scaling convenient. Here I would go for: - Prescaled data columns - Precomputed offsets for the height where the sprite columns starts on the screen - Precomputed number of bytes composing a column The screen columns where sprites appear have to be optimized separately when you go to RAM to VRAM transfer according to the height where the sprite column starts Edited September 19, 2020 by artrag 2 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 19, 2020 Share Posted September 19, 2020 Probably with some extra side data in the prescaled sprite columns it should also possible to overcome the limitation of fully convex sprites. You can encode separately two or more 'runs' of connected pixels belonging to the same column, each with its starting point and its length. The metadata describing a sprite texture for a given distance should be a collection of pointers to the data runs telling for each X offset there is zero, one or more than one data run Naturally the offline encoder has to process sprite images accordingly Quote Link to comment Share on other sites More sharing options...
Elia Spallanzani fdt Posted September 19, 2020 Share Posted September 19, 2020 Would there be a big slowdown if the images of the walls were animated? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 19, 2020 Author Share Posted September 19, 2020 2 hours ago, Elia Spallanzani fdt said: Would there be a big slowdown if the images of the walls were animated? Yes. Quote Link to comment Share on other sites More sharing options...
Elia Spallanzani fdt Posted September 19, 2020 Share Posted September 19, 2020 (edited) Oh... thought it was a question of replacing one texture with another. Edited September 19, 2020 by Elia Spallanzani fdt Correction Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 19, 2020 Author Share Posted September 19, 2020 2 hours ago, Elia Spallanzani fdt said: Oh... thought it was a question of replacing one texture with another. It depends on what you mean by animated, of course. Quote Link to comment Share on other sites More sharing options...
artrag Posted September 19, 2020 Share Posted September 19, 2020 13 minutes ago, Asmusr said: It depends on what you mean by animated, of course. If you think to flame in torches you could update only few columns per frame It is complex but doable Anyway all is matter of compromises, the same CPU time could have better use 1 Quote Link to comment Share on other sites More sharing options...
Elia Spallanzani fdt Posted September 19, 2020 Share Posted September 19, 2020 (edited) thought, for example: a block of the wall with a monster face, opening its mouth and launching a bullet. It might be less expensive than making a sprite of it. Edited September 19, 2020 by Elia Spallanzani fdt Correction 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 20, 2020 Share Posted September 20, 2020 (edited) 21 hours ago, artrag said: Probably with some extra side data in the prescaled sprite columns it should also possible to overcome the limitation of fully convex sprites. You can encode separately two or more 'runs' of connected pixels belonging to the same column, each with its starting point and its length. The metadata describing a sprite texture for a given distance should be a collection of pointers to the data runs telling for each X offset there is zero, one or more than one data run Naturally the offline encoder has to process sprite images accordingly In addition you can optimize texture data in order to remove repeated columns/runs of pixels. If the offline encoder finds a run identical to a run of pixels aready encoded it can encode it by a pointer in the texture metadata to the previous run, avoiding to store that run a second time. All the symmetrical pictures will cost half of their bytes, while e.g. flat columns will be reused many times across all textures Edited September 20, 2020 by artrag 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 21, 2020 Author Share Posted September 21, 2020 I fixed an error in the texture drawing code, so instead of this: We now get this: @artrag Thank you for the suggestions regarding sprite drawing optimizations. I haven't decided how to proceed with that yet. 11 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 22, 2020 Share Posted September 22, 2020 (edited) A nice snippet in z80 assembly to copy bytes to VRAM consists in an unrolled subroutine of e.g. 128 instructions for copying 128 bytes and a header able to jump to the right place within the 128 instructions according to the actual number of bytes to copy. Edited September 22, 2020 by artrag 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 25, 2020 Author Share Posted September 25, 2020 As mentioned before, I have been considering changing the texture resolution from 16x64 to 32x64. I tried with the eye, and a new 32x64 texture looks like this: Whereas the old 16x64 texture looks like this: 11 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 25, 2020 Share Posted September 25, 2020 Awesome! Quote Link to comment Share on other sites More sharing options...
artrag Posted September 27, 2020 Share Posted September 27, 2020 (edited) About floor and ceiling (or for a side project) you might be interested in this https://github.com/MartinezTorres/msx-karts You can see it online here https://webmsx.org/?ROM=https://github.com/MartinezTorres/msx-karts/releases/download/v0.01/msx-karts.rom&CARTRIDGE1_FORMAT=ASCII8 Edited September 27, 2020 by artrag 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted September 27, 2020 Share Posted September 27, 2020 Ps now that you plot column by column you could consider to avoid to buffer in ram the 6KB of color table. You could store in a ram buffer just one column for left pixels, one column for right pixels (generated by the same unrolled loops from data with different offsets) and merge them and send the results to VRAM. Maybe it can fit in scratch pad getting higher speed Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 27, 2020 Author Share Posted September 27, 2020 4 hours ago, artrag said: Ps now that you plot column by column you could consider to avoid to buffer in ram the 6KB of color table. You could store in a ram buffer just one column for left pixels, one column for right pixels (generated by the same unrolled loops from data with different offsets) and merge them and send the results to VRAM. Maybe it can fit in scratch pad getting higher speed It wouldn't work with the current code because I'm drawing the sprites one by one after drawing the entire ceiling/walls/floor. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted September 28, 2020 Share Posted September 28, 2020 On 9/25/2020 at 3:01 PM, Asmusr said: Eye can feel it, eye can feel it... I'm afraid. Will you stop... Dave? 1 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.