The Icarus Engine, a variable wall height ray caster

Hello. I've already said my intro in the message board for that stuff, so let's cut to the chase. Icarus is a variable wall height renderer which I have been working on for the past 2 and a half months. It is in full ASM, so that I can optimise it %100; I'm gonna need it. As of now, it doesn't run, but hopefully it will by the end of the Christmas break. It is currently small enough to be a library, but it may get to the point where it has to be a DLL; hopefully not. Here is what Icarus should support when it is through:

1. Variable wall heights
2. Vertical looking and moving. This means one can jump, fly, crouch, climb stairs, ladders, whatever.
3. Horizontal moving.
4. Wall format is the regular 90 degree to each wall thing, like the FAT engine or Wolfenstein3d.
5. inset/not inset doors set ONLY at the top of a wall. Having them set anywhere on/in the wall is too complicated and slow.
6. framerate above 10 fps. VERY important.
7. sprite support with 8 angle thing. Think Doom95 type stuff.

That's all I can remember at the moment. If you have any questions, please ask them. Also, I am programming this engine so that I can program Metroid Prime 68k, a clone of Metroid Prime with elements from all 3. When I finish the Icarus engine, I'll make a project thread on Metroid Prime 68k.

I am looking forward to concept shots and what not. I am really interested in seeing how this engine works out, because once I am done with my z80 basic projects, I wanted to make one on the 68k, in C.

Hi SuperCoolKid, i've seen your project at the tict messageboard. This project looks really interesting! An engile like this will be a major step in calculator FPS games, and will push the limits for what is possible to do with a calculator!

I wish you all good luck with your project, and i'm looking forward to see Icarus spring to life.

BTW, There are some screenshots of this at the tict messageboard.

http://p094.ezboard.com/ftichessteamhqfrm1...tart=61&stop=80

(by some reason IE messed up when i tried to use the link button ? )

Thanks. I have a small, but significant update. Icarus recompiled today! I finally finish reworking and rewriting all the neccessary functions, hit compile, and watched the calc crash . So I've been debugging it for a while now. I've found one important logic error that I've been trying to find the best way to solve, but it's pretty complicated. I'll post later when something comes up.

usually a wonderfull feeling when something goes correctly... Wish i could feel it soon... :S

Another small update. I've found a solution to that mind boggling problem, but it's definately not the best one. I'll have to sit down one day for 3 hours and work it all out in my head, but right now, I'm moving on to bigger problems. I've been working on opcode optimisation in all of my functions. For example, I saved several hundred, maybe thousand, clock cycles by cutting out most division, multiplication, and regular modulu operations. Instead, I've found faster ways that use more space and regs, but less time.

Another thing I've done is cut out using masks to set/clear pixels onscreen. I found out that bset ---- has the exact same speed as or ----, only bset requires less pre-calculation, thus saving time. That's the only major thing that's happened; if I say anything minor, I'll go WAY off topic .

Oh! and I found out that in order to have a good fps rate, The amount of average clock cycles for rendering one frame has to be around 888,888, give or take a couple hundred thousand; at least now I have a goal to shoot for!

[EDIT] I've also been thinking that this engine would not be limited to fps games. I was playing LoZ: Phantom Hourglass the other day and realized that topdown 2d games could be done in 3d, just set the camera height above the player, and looking down! It would take a few tweaks, and the player would probably not need to be scaled (just drawn onto screen), but it would be possible. Just to give y'all something to think about.

congrats on the staff promotion!!

Thanks! That's one step closer to taking over the world !

Congrats with the staff promotion, SoperCoolKid !

SoperCoolKid? I don't get it... Didja see my avatar? Pretty awsome, huh. I spent an hour working on it, though it should've taken only 10 minutes. Darn computer hates me.

LOL, sometimes i'm drunk when i type...

Awesome avatar, SuperKoolKid!

Then how in the world did you pull together SM68k? jk

On a more serious note, I have some bad news, and some good news. Icarus is at a stage where I can pretty much accurately predict the framerate, based on the clock cycles of each function. So it is to my horror that I found out that with a draw distance of ten loops, and a screen size of 96x96, The frame per second rate would be about 1. Now there are still many, many ways I could optimise Icarus, and I will, but it probably won't get above 3-6 fps. The thing that drags it down is scaling textures - ~%75 of the time spent is done in the scaling loop. Lowering the screen size drastically lowers the clock cycles, but only to about 5-7 fps.

Tha doesn't mean Icarus would be unusable, that just means you can't use it for complex games. Now for the good news - Icarus coulds still be used for complex games, but without texture mapping or scaled sprites. Drawing a colored coloumn onscreen is highly optimiseable, and even my unoptimised version is running at around 1000-3000 clock cycles. With my current unoptimised version of Icarus, the framerate could get up to 8 fps; with a smaller screen size, say 64x64 or even 48x48, and mopre optimisations it could get about as fast, or even faster, than the FAT engine, around 10-18 fps! Note; this is without doors and sprite support.

So I've decided that I will release 2 versions of Icarus. One with texture mapping, and one without. Right now, I will continue to work on the former version, then optimise it as much as possible. Maybe my calculations are incorrect, maybe not. Afterwards I will work on the latter. Sorry for this bad news. \/_\/

Without scaling, Metroid Prime 68k woudn't be a very good game, cause of the lack of scaled sprites. umm... I think I'll go cry now.

[EDIT] Ignore everything I just said.

Well, I didn't cry, so I thunk instead. Metroid PRime 68k could still be (barely) playable, AND have scaled sprites. texture mapping takes up a TON of time. But scaling sprites probably wouldn't take nearly as long as texture mapping if we only used one or two strips per sprite. The whole 4 strips would take about as long to scale as texture mapping. So having only scaled sprites and no texture mapping copuld be a possibility.

[EDIT] Ignore everything I just said

You know what? Thinking about how MP68k is going to be an unplayable game is too depressing, so I'm gonna do a memory wipe of that section of my mind that constantly reminds me of that fact. ... Done! Alright! Metroid Prime 68k is going to be a wonderful game, don't you think?

PS: I actually feel better now. What was I so worked up about earlier?

[EDIT] I just found out what was wrong with me today! I didn't drink my coffee! and Ignore everything I said

I know my posts are getting kind of excessive, but bear with me for today. After eating a good meal, I suddenly feel much better, and I don't care how slow Icarus may be; I'll still love it, no matter how disabled it is . Slow shmoe! Must've been something my mom put in the beef. . BTW, I am in the process of cutting out most stack pushes and pops to pass parameters. Instead, I am switching to the more efficient mixture of global vars and regparm stuff. I looked over my code and found out that there are a LOT of vars that are passed to every or most functions, and a lot of those functions are called in loops. So I am shaving of something like 30000-70000 clock cycles with this. also, I realized that I could do similar type stuff which reduce clokc cycles even more in MANY more places. Perhaps Icarus does have a chance after all.

PS: "Never give up! Never surrender!" - a quote from some movie. I'm not gonna give up.