cast8k

by Calus CoRPS
A Raycasting Engine 3D
ID:106830
 
About:
Cast8k is a ray-caster engine that is around 8k in size. The current download is a demonstration of how it preforms.

Recent Changes:
Wall Textures (There will be some initial lag with this update. I will fix this problem once I have time.)
Smoother Movement

Existing Bugs:
Texture Lag
Graphical Glitches

To-do List:
Sprites (Expected Completion Date: January)
trololo.

* Posts on Cast8k Comments asking for the source *

Oh hai. good work. :D
Thanks!
Fix the lag issue. I've been following this for a while and I wanna see more of it : )
Makeii wrote:
Fix the lag issue. I've been following this for a while and I wanna see more of it : )

Unfortunately, I am afraid there is not much I can do with the lag. I've requested for icon procedures to be improved, but I doubt it'll happen.

The engine works rather fast when I remove all textures and just go with solid colors. I am currently working on castZk, which displays different height/z levels and it would only use solid colors.
Rather than displaying thin icons in the engine here, I would suggest producing an /image object every time the screen is updated.

Makeii wrote:
Rather than displaying thin icons in the engine here, I would suggest producing an /image object every time the screen is updated.

But, I would still have to use the icon procedures to create the thin icons that are not cached, correct? The slow movement is due to the icon procedures, not displaying them on the map.
Infinite loop suspected--switching proc to background.
If it is not an infinite loop, either do 'set background=1' or set world.loop_checks=0.
proc name: rayCaster (/mob/proc/rayCaster)
source file: cast8k.dm,99
usr: Kaiochao (/mob)
src: Kaiochao (/mob)
call stack:
Kaiochao (/mob): rayCaster()
Kaiochao (/client): West()
Instead of making these slivers out of icons, I would simply DrawBox all of this into one icon and then display it on the map rather than Scaling it (or otherwise)
@Kaiochao
Oh yeah, I forgot to update this with a fix. I'll do that soon.

@Makeii
That would work well with a solid wall, but what about the textured ones?
In the same operations that you applied with the textures, write the slivers on that particular section of the image.

The image is probably going to be drawn using two nested for loops anywho : p
hate to burst your bubble mate but this is bull compared to the vengence 56 graphics engine
In response to Bumblemore
Bumblemore wrote:
hate to burst your bubble mate but this is bull compared to the vengence 56 graphics engine

Yes, Gaku did not use textures while my demonstration did. If I were to remove the textures and have two basic colors for the walls, it would run a lot faster.

But I'm not interested in doing so as I no longer create "proof-of-concept" demonstrations. They always amount to nothing as they are not feasible to be made into a game.
In response to Calus CoRPS
Calus CoRPS wrote:
But I'm not interested in doing so as I no longer create "proof-of-concept" demonstrations. They always amount to nothing as they are not feasible to be made into a game.

except vengence 56
In response to Bumblemore
Bumblemore wrote:
Calus CoRPS wrote:
But I'm not interested in doing so as I no longer create "proof-of-concept" demonstrations. They always amount to nothing as they are not feasible to be made into a game.

except vengence 56

What?

Once again, that game does not use textures. Sure, I could remove the textures and make a game like vengence 56. But this is only impressive BYOND-wise and it gets laggy once you start having multiple players. Outside of this community, no one would play it. My goal at the moment is to make a fun game, period. Not just an impressive game for a small BYOND community.
In response to Calus CoRPS
i find vengence 56 fun, and once again it does use textures you dick check the source
In response to Bumblemore
Bumblemore wrote:
i find vengence 56 fun, and once again it does use textures you dick check the source

The source code is not available, at least to my knowledge. To correct my previous statement, V56 uses a basic texture: each wall contains essentially 2-4 colors (probably just 2). This decreases the lag substantially as you would only need to size up 4 color stripes.

With cast8k, it uses whole textures. So for a 64x64 texture, I have to create almost 256 different sizes for each 1x64 strip. Lets say I have a brick wall which does not repeat. That'll mean I'll have 16384 icons generated at runtime for just that wall. Now add in a door, window, and so on.

I've gone Gakus route and essentially made walls 2-4 colors, thus only having to create 512-1024 icons at runtime. It ran smoothly like Gakus game. But when compared to an indie game shooter, V56 and this does not compare. BYOND players typically have lower standards when compared to the rest of the indie community. Which is why we have "BYOND games" and not "great indie games".

tl;dr - This uses more complex textures, like it or not. Have fun playing V56 though!