The most terrible thing has happened... I accidentally deleted the most current un-compiled version of my program and my dumbass got rid of undelete. The last backup I did was like 2 months ago and is 1/4th the size so I'm not going to go back to that. I had been developing it really slowly like maybe a line every other day, so I didn't want to get rid of the "paused". Thankfully, I still had a compiled program that works pretty well and shows what I had been doing (besides a very small debug test with the walls) with no known bugs. I will be putting that in the cemetech archives/the github page and a screenshot here later today so you guys can look at things. I guess there is a silver lining to this because it will force me to start making a more efficient one in C or asm.

- got rid of almost all fisheye (except when really far/close away)
- cool wall pattern to make it look even more 3D
- dual enemy sprite rendering (kinda weird because its in a very small space at the start)
- FPS: increased from 7-9 to 10-12 with enemies, increased from 11-13 to 12-14 at regular sized areas.

- strafing: mode/del
- movement: top/bottom arrow keys
- rotation: left/right arrow keys
- shoot: 2nd
- reload: alpha (or 2nd when you are out of bullets)
- exit game: graph then enter

Note: shooting doesn't do anything besides the animation, it will not kill an enemy (that was what I was working on when I accidentally deleted it)
Dang that sucks man!

After experiencing similar disasters myself I recommend a regular backup routine.
It's alright, I wasn't developing it a lot but I will most definitely be taking a lot more countermeasures against this. Anyway, I put it in the archives and here is a screenshot:

I found an old backup on my Pc without any of the sprites or anything but it had the base code and I quickly added the optimizations (: I still plan on getting a laptop to do C but haven't gotten one yet so I'm just going to do some optimizations on the ICE version. I need some help with this part:

REMY+Sθ→REMY // Sθ is the sin(angle) I use θ for angle
REMX+Cθ→REMX // Cθ is the cos(angle) RÉMY and REMX are remainders (255 = 1 because it gets rid of a calculation for transitions.

If REMY≥765  // I keep the remainders at 255*2 so it never goes negative and weird things happen (I think negs do work with sub and add tho)
REMY-255→REMY // sin and cos go from -255 to 255
TESTY-1→TESTY // TESTY and TESTX are the x and y of the point where the ray tests to see if it should draw a wall
If REMY≤255

If REMX≥765
If REMX≤255

I feel like this should be really easy but I'm just brain farting because I want to be able to keep the negative number (multiplication and division messes negative numbers up) Also, this code is repeated around 300 times per frame so literally any optimizations will most likely increase the frame rate a ton. It would also be better if it is able to do more than one point movement (with the code above, if REMX is 10000 the test point will still only go up one) I plan on making it be able to skip points as an optimization.

Last note:
Without all of the extra sprite rendering of the gun and cool looking things, The lowest FPS I've seen is 18 Surprised
You can use TIPlanet's project builder.
It's very good for use on the go. (If you have a chromebook, for example, or if you can't set up the toolchain on Windows)
I'm going to be picking up this project again, even if it's not a great idea with AP tests coming up Razz I recently was able to figure out the fisheye correction Very Happy . Since there are no floats, it still doesn't look perfect but a ton better.

I plan on changing it from ray casting by looking at a sprite on a screen to a matrix (list but with extra steps) this will allow it to get as big as you want (up to memory) without printing out onto the screen and eating frames by the dozen. I don't think it will speed up the actual ray casting compared to the on screen pixel tests but I think it will be worth it.

Of course with this new and amazing lists as the map instead of sprites, I will also be adding a map creator/editor that stores them as appvars. I've already made that in a past project for fun, so all I have to do is implement it in the raycasting.

This is looking far into the future, but I'm thinking that a sort of 3D maze game would be the most simple and cool for this project. (:

I'll be uploading the fish-eye corrected sometime soon (with source of course)

Looking at the screenshot above, I also realized I added corner color changes so it has more depth, improving it a ton
I was able to change it to using a matrix that was saved as an appvar. This first gif is of the map editor a made (still some bugs):

And here is the raycaster using a matrix:

In that screenshot, it shows like 6/7 fps because its drawing the map and the raycasting lines but it gets about 12-14 fps. At the moment, the sprite and matrix are about the same size because the matrix does pixels while the sprite is tiny but scaled up a ton. Later, ill add the ability to set the size of the list, the scale, and other things all stored in the appvar that the program would read. Ill also have to test how big I can make the list to make sure there isn't a limit.

The fisheye corrected raycaster is still being approved on the chemtech archives, so just visit my github if u want it sooner (the matrix-using version is also going to be there with the map editor)
That's pretty impressive, I didn't imagine ice was capable of something like this! Great work!
Thin walls? I like it! Speed is pretty decent too, especially for something like this in ICE.

EDIT - I noticed that you have skinny walls and diagonal walls too? Is that the case for the renderer or have you done something like making the cell sizes very small to simulate it instead (clever if so)?
Thanks for all the support Very Happy

The skinny walls can happen because making the map in a list has a much higher resolution than displaying a sprite, and the skinny diagonal walls are just pixels going diagonally haha

There haven't been any optimizations yet with the matrix map so I'm sure ill be able to squeeze out a few frames.

I was experimenting with the map size, and I found that it could get up to around 200X200 which is kinda insane Surprised (for reference the map in the screenshot was 48X48) It also doesn't effect the speed because its not printing the map for ray casting. I'm not sure how editing would work with the larger maps, but ill make it so everything is customizable when making a map so you can choose a smaller map.
I have just finished a pretty chunky update, so its and Easter update I guess Smile

- Maps are now able to go from 10x10 to around 200x200 and both the editor and ray casting engine automatically are able to use the entire map without any changes in settings
- The ability to turn on and off debug mode while in the program (the debug mode draws the rays and map so the fps is substantially decreased with it on)
- A menu system (in game) that isn't fully finished but will be able to change maximum ray distance, the resolution, the map scale, and more.
- In the map editor, you can set a spawn point, and if you don't the ray caster will just put you at (1, 1)

- I found that with a resolution of 10 pixels per ray instead of 5 is a ton faster and looses almost no perception
- The map editor is now a bit more optimized and archives the maps so they don't get deleted (also during editing if something happens)
- As both programs load the map, it shows what is happening (sort of like a terminal on boot of a pc) so you know it hasn't frozen or something
- Made it not possible to play the raycaster without an existing map because there is no point to have an empty map (and it could help people struggling with maps too)
- The map editor automatically puts walls on the edges of the map when opening or creating a map

Things I'm working on right now:
- I though to a very good optimization that might work that uses the remainder( function instead of manually doing that
- changing the ICE pallet so I could make walls get darker slowly as it gets farther away
- Trying to find an optimization for finding which way a wall is facing (because its taking at least 4 fps but is super needed)
- The in-game menu
- Quality of life improvements with the map editor
- letting you do different colored walls with the map editor (and they would be seen as that color in the raycaster). this is the main reason I want to figure out custom ICE color palets
- saving the settings an an appvar (separate from map)
- an FPS limiter so it doesn't randomly speed up
- A really weird glitch where going backwards while strafing reverses the strafe direction (not with any other keys so idk)
- figuring out how to do map scaling. If you want a 400x400 map, you would be able to do a 100x100 at 4 times scale.

At the moment, the raycaster runs (on average) around 14 to 16 fps with 11 fps lows (when rays have to go far)

Happy Easter or whatever holiday is today for you Very Happy

I was actually able to get access to a computer and uploaded both on the cemetech archives (still being approved) and on my github if you want it sooner.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 4
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum