While I was showing my friend my program, he asked if I could get rid of the pause after you press a key. You can see it in the video I posted where you press a key, it immediately moves but then it pauses for a tiny bit, then moves smoothly. I’ve tried to come up with ways to get rid of this like only storing getkey into K if it isn’t 0 but it would just never stop moving.

I got CEmu animated screenshots working Here it is:





For this one I got rid of the map because I found I was getting distracted by it and using it more then actually looking at the render. I'll add an option to turn it on or off. Also the top right is the frames per 100ms so its not fps (fps/10)

Nice work on getting it set up to work with CEmu, much easier development and debugging.

Still running 10+ fps, pretty good if you ask me!

Before I do anything with the rays or colors I’m going to be fixing my brain fart-ness today and maybe tomorrow haha. What I was doing was putting all sin and cos values into a list so I could use them instead of just using the ICE sin or cos the dividing by 256 changing that over will probably around half the size of the program (and maybe even almost double the FPS ) I’m not really sure why I didn’t do this earlier but I think me just not wanting to have to deal with it and being lazy helped.

If you do that now and it works,
can you please post how the FPS and memory usage of your program have changed in numbers?
Thank you.

I think I found an ICE compiler problem:



if you don't want to watch to the end (like a few min) basically the ICE compiler crashes when there is a sin function (I was able to narrow it down with the program I show in the screenshot) I already reloaded ICE and ICEHOOKS so that's not the problem.

Bump - it’s been a few days without any answer from this post or the one I put in the ice help forum. I can’t do anything until I can figure this out so any help would be awesome

Do you mean that ICE won't compile programs that have a sine function in them or is it something else?

Yes. On the documentation it shows that sin works and everything but when I use the latest stable version of ICE it crashes while compiling. I even was able to take down the code to

Code:

And it still crashes while compiling. I even used a number that they showed in the documentation

here is a link to a more in-detail post:
https://www.cemetech.net/forum/viewtopic.php?t=12616&postdays=0&postorder=asc&start=620

It turns out that there was a problem with my OS (5.0) so I updated to 5.3 and it works perfectly

here is a link to 5.3 OS
https://tiplanet.org/forum/archives_voir.php?id=1138252

I have finished with changing everything to sin( and cos( instead of accessing a value table and its kind of crazy how much better it got. First, the file size: it used to be over 2.2k un-compiled and around 2.5-2.7k compiled. now it 1.6k un-compiled and just a bit over 2k compiled. Second, the FPS: it around ×3 the speed which is insane.

While I had some free-time today, I was able to do the different amount degree/ray there isn't a menu in game yet but all I have to do is change a value at the beginning. Here is a screen shot of 1° per ray for a circle that has 255° in it, which adds to around 50 rays (because of the FOV being 50°)



As you can see, its getting pretty stable frames even when on max resolution there is a black rectangle on the right that I plan on changing to white and putting it on either side as a frame (it's from the screen not fitting the amount of rays perfectly)

Now all I need to do is change up the colors, scaling, optimize a bit more and add in-game menus for coolness

Nice work, this is taking shape quite nicely! I'm glad you were able to decrease the filesize while also increasing the speed!

So I’ve been trying to fix this problem:


And I ran across these that are for using hexadecimal with basic programs
http://tibasicdev.wikidot.com/84cse:hexcodes - for the CEs
http://tibasicdev.wikidot.com/hexcodes#toc2 - for older calcs

And in there there is something called quick key (exactly what I’m trying to do) so I tried doing this in ice with the Asm( token (can add hexadecimal asm into an ICE prgm according to the documentation). The hexadecimal for the older calcs just clears the ram and the other one stops the program. Is there a different hexadecimal table for ICE? Or does it just not work? I’m kind of in over my head with the hexadecimal stuff so I’m not sure

I just did collisions in less than 3 minutes just now I was definitely overthinking it before lol

This is coming along great! I can't wait to see even more progress in the future!

I have two kind of random questions:

1. How would you calculate where a wall starts and ends for a wireframe with rays? (Please don’t make me use matrices because I would have to make a list (yay ICE) and would have to think about that )
2. Even though I’m probably not going to do this, how would I add textures to walls? There isn’t any way to scale one side of a sprite in ICE (without making my own time-hungry function)

Also, I’m probably going to be adding objects that scale and stuff if I have enough time today (like a coin) soon so be ready for more questions

I made it so there wasn't a delay for when you press a key (instead of using the quick key hexadecimal asm( thing I just used getkey() instead of getkey→K) it feels like I doubled the frame rate even though its the exact same Ill get screenshots tomorrow morning.

Sorry for me posting on here and the ICE sticky randomly and me jumping around questions and celebrations for my program also, thanks to all the people who are helping

Edit:
good morning here's an amazing screen shot:



Here's the github page

if there are any changes I should make please tell me

The screenshot looks good, I like how you're using different shades to indicate depth. With that said, here are a few things I would improve:

• You seem to have the so-called "fisheye" effect, which can be fixed by measuring the distance from the line perpendicular to the camera angle instead of from the camera to the point, which is probably what you're doing currently. Here is a source that I found that you should be able to use to fix the problem.
  
• I would change the camera indicator in the minimap back to red, as the yellow is nearly impossible to see. It looks like you changed that pretty recently.

Keep up the good work!

I've not yet dabbled in ray casting so I can't offer much in the way of constructive feedback or advice, but I'm enjoying what you've come up with! Are you still planning to eventually use this engine to make a complete game? And if so, any hints on what kind of game it will be?

Looks great and I agree with the fisheye distortion - it's not too bad but correcting it may help visually a bit.

I was also wondering what it would look like with the colour gradient reversed so that it's darker the further away a wall is?