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 Laughing 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 Razz changing that over will probably around half the size of the program (and maybe even almost double the FPS Laughing) 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 Smile
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

iICECOMP //the name of the program it compiles into

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

here is a link to a more in-detail post:
It turns out that there was a problem with my OS (5.0) so I updated to 5.3 and it works perfectly Very Happy

here is a link to 5.3 OS
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 Very Happy 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:
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.

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 Razz
I just did collisions in less than 3 minutes just now Razz 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 Sad)
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 Razz
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 Very Happy 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 Razz also, thanks to all the people who are helping Smile

good morning Very Happy here's an amazing screen shot:

Here's the github page

if there are any changes I should make please tell me Smile
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?
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 2 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