not really a project of mine, just a preview of what my next big engine dealie thingy will be; I'll be tackling the old favorite RAYCASTING. So in hopefully a weeks time or so, I'll have a full raycasting engine, with variable texture mapping, clipped sprites, a good draw distance, no fishbowl effect, and most importantly, *NO SLOWDOWN* (really), fully based in MMF1.5 with gratuitous usage of the overlay object. In other words, an engine roughly comparable to wolfenstein 3d, for your programming learning, comprehension, and code pilfering. I've already got it mostly done, I'm just a bit lazy on adding in the sprites bit, and who knows, I might have a secret Epic Game planned off it for this stage of Peblo's compo. But anyone whos ever had problems trying to tackle the 3d engine-in-mmf issue will be free to take a looksy at the sourcy.
Err... no. Any type of "3D" on a computer is technically not 3D. It's a 2D representation of 3D. So this is just as much 3D as anything that uses models. True 3D won't happen until holodecks. (Well, we have holograms now I guess...)
So what does this "real" 3D consist of if not images?
It's quite narrow minded to say that something that does meet the requirements of three dimensions isn't 3D just because it doesn't use the conventional means of creating and handling mass in it's 3D space.
(From wikipedia on 3D Computer Graphics)
"3D computer graphics (in contrast to 2D computer graphics) are graphics that use a three-dimensional representation of geometric data that is stored in the computer for the purposes of performing calculations and rendering 2D images."
"Real" 3D is (From wikipedia on 3D) "A vector space or coordinate space with three dimensions". It's damn hard to tell what consists a 3D engine.
theres no good way to differentiate it. It just means that people consider raycasting "2.5d", since it doesn't allow for full vertical viewing. The only thing that keeps me from making a 'Full' MMF 3D engine, is that I don't have a way to map textures onto polygons. I can only use the overlay object to stretch rectangles into other rectangles, which isn't time consuming, but if I wanted to stretch a rectangle bitmap into an abnormal polygon, I'd have to write some script that does it at runtime, which would be so inefficient the whole thing would run at 0.0000001 FPS.
so I'll settle for popping out a nice wolkensteiner engine
you can use the 3d mesh object pixeltheif. not sure if it works like an active though. multiple instances?
oh and the only way to get "real" 3d is to project onto a physical 3 dimensional space. everything else is just a 2dimensional representation of a 3dimensional space.
Originally Posted by cecil64 oh and the only way to get "real" 3d is to project onto a physical 3 dimensional space. everything else is just a 2dimensional representation of a 3dimensional space.
Yes, but having the player be able to walk forward into a room, turn right a few steps then turning 180 degrees and still see the correct image consist some sort of Z-axis?
7 axis movement is possible. it is just impossible to do true z axis rotations in raycasting. so you can jump up and down and go up stairs n what not, but you cant "look" up and down.
If I simply moved the Y coordinate where each line of the wall is drawn by a percentage, it will give the illusion of moving upward, and the inverse for downward. And just move the sprites up/down accordingly. This can give the illusion of jumping/crouching, but in reality no new information is being displayed; you can't view surfaces you couldn't before, etc. And the further I skew up and down, the more obviously fake it is. After a handful of pixels, it looks like I'm just shifting the display up and down.
Sadly my FPS has taken a hit since I modified it to load textures from files, so I'm going to need to rewrite a bit so that it can have a variable rsolution; the 3 pixel-per-column for 200 total columns is a bit taxing on MMF. I think most peoples computers would run it, but it gets to be ~30 FPS if you get into a big open area with lots of different textures.
well i guess since the engine im using doesnt use raycasting but simple maths related to all objects to display said objects properly scaled and positioned you CAN see new surfaces by adding and subtracting from the y values.
in werbads open sourced engine there is a few events commented out by "never" statements.
take out those never statements to enable "jumping" and youll see it in action.
If you are going to do an "eyeofthebeholder-esque" game you could always use a dungeon crawler engine, there are a few nice open source ones here on tdc, the programming is far easier with those. You can check these out:
I've been working on and off with my own dungeon crawler engine including halfsteps and a very simple rotation effect so you don't lose your orientation in dark and murky dungeons...
Originally Posted by alspal Will you do anything for the ground? Use mode7 or something?
I know the math of how to use a further raycasting effect to display ground & ceilings in the overlay just like the walls with http://www.permadi.com/tutorial/raycast/rayc12.html but that might be a little excessive. Likewise with Mode7; I'm having troubles layering it too, although I think if I used an active overlay it would work. But the main concern is that it would kill the games speed, I mean I already had to implement a multi-resolution system because good ones slow down on some computers. Rendering floors too might kill it.
Originally Posted by Pixelthief you can't do Z-axis in raycasting systems. You can create an illusion, like doom did, by simply displacing the graphics
Thats what i meant, but now i think about it the extra impact it would have on the processor would probably be ridiculous even if possible.
well its just not possible in MMF, the system dies under the kind of slowdown full 3d engines create. Doing nothing but drawing flat sprites to the screen in rectangles is enough to pull it to 30 FPS on my computer, imagine trying to map that to polygons in wire meshes. No the overhead in MMF is just too inefficient. It can easily be done in languages like C, and has of course been done to death.
the mode7ex object i have found is only effective at super low resolutions like 320x200 otherwise it takes a toll on speed as pixeltheif said. for an old school wolfenstein engine, different colored floors and ceilings will do fine.
yeah MMF is just plain slow. Theres really two limiting factors; the amount of draw calls to the overlay object per frame, and the amount of raycast checks run. For example, if you simply create a program where all it does is draw a single pixel in the overlay object, 640 * 480 times per frame, you'll get maybe 1 frame per second. Likewise, if you check 100 times per ray, and cast 600 rays, for 60000 ray-checks per frame, your game will devour the cpu and die. In a language like C this would run fine on my computer, but MMF needs a lot of overhead per action, so more complicated things run much slower than they should. The result is that I need to limit the games resolution, drawing only vertical columns, and make each one 4-5 pixels wide, for a total of ~150 draws per frame, and then both limit the sight range of the player, and only check for collisions along intersections with the grid. I could program a better engine, but not in MMF.
if youre using actual raycasting and vertical column drawing, you can probably increase performance by allowing reduction in quality (wider columns being drawn, meaning less rays being cast at wider angles) and reducing the draw depth.
it really depends on if I can find a way to optimize the raycasting algorithm. I used caching so that sprite loading/drawing has no impact on FPS, but the simple math behind raycasting, seems to be too much. I think if I find some changes to optimize it I could potentially have graphics just as crisp as that, running at 50 FPS. That games has a resolution of 1 pixel/ray, which requires 512 rays to be cast, each one checking maybe 20-40 collisions in a worst case (empty field of view) scenario. One reason that game might run particularly fine is because it appears the collision grid for walls is HUGE; it looks like your vision range is never more than 6 or 7 squares total. I'm intending to write my code for doom or at least wolfenstein level graphics. Push the boundaries of MMF
The real difficulty of Klik is that nobody really knows what the limiting factors in any engine will be. If it were in C++, I could google my issues and find 100 articles about optimization. But in MMF, you have to experiment and do trial/error studies to discover why something is running slowly. For example, with my text based one, I initially found that as soon as I made it strings instead of textures, the game collapsed. This as it turned out, is because strings are immutable in MMF, and thus when you append them, you are making and requiring memory for a 3rd string, instead of altering the existing one. So appending 1560 characters at runtime took out memory for Σ1560 strings. Youch. Next I found that the overlay objects "Load image from file" turned out to be a limiting factor; running this inside of a loop will significantly lower the frame rate. Answer? Create extra overlay objects to serve as buffers, as pasting from an overlay to overlay takes no time at all compared to loading from a file.
Now my issue is with raycasting itself. Drawing the sprites & walls on screen is taking no processing time, instead the actual raycasting algorithm, which follows this: http://www.permadi.com/tutorial/raycast/rayc1.html very closely, is an issue. Projecting 600 rays per frame, each of which checks 40 array-collisions, seems to be too much for MMF. Now its back to the blocks of experimenting, and finding out what piece of code is the limiting factor. Is it the "Find distance to object" on the advanced math object? Is it the "Check array @ XY"? is it the very act of running 600 * 50 loops? Who the heck knows.
moral is, I'll probably post the darned thing open source later today.
Advertisement
Post Reply
(Well, we have holograms now I guess...)
Edited by the Author.
I have downloaded them, so I am going to check them out soon. Thanks! 
