Jump to content

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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 by Kiwi
  • Like 1

Share this post


Link to post
Share on other sites

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 by Asmusr
  • Like 14

Share this post


Link to post
Share on other sites

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. ;)

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by artrag
  • Like 2

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites
2 hours ago, Elia Spallanzani fdt said:

Would there be a big slowdown if the images of the walls were animated?

Yes.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

  • Like 1

Share this post


Link to post
Share on other sites

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 by Elia Spallanzani fdt
Correction
  • Like 1

Share this post


Link to post
Share on other sites
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 by artrag
  • Like 1

Share this post


Link to post
Share on other sites

I fixed an error in the texture drawing code, so instead of this:

js99er-20200921132743.png.178ff05d75e1632374d91d50f1ab1193.png

We now get this:

js99er-20200921204556.png.199a75efc761302d5b6442c4270449e9.png

 

@artrag Thank you for the suggestions regarding sprite drawing optimizations. I haven't decided how to proceed with that yet.

  • Like 11
  • Thanks 1

Share this post


Link to post
Share on other sites

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 by artrag
  • Like 2

Share this post


Link to post
Share on other sites

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:

 

js99er-20200925201545.png.951a15697f12260be22093b71f7f06da.png

 

Whereas the old 16x64 texture looks like this:

 

js99er-20200925201736.png.40fae43f8fadf843ef8e4c8d299bda2d.png

 

  • Like 11

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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.

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   1 member

×
×
  • Create New...