I’m making an ICE raycast engine/game for fun and because I haven’t found any other ICE 3D things I decided to make a post for it so I can just ask questions here instead of making a bunch of other posts. I’m modeling it pretty close to this (go down to iPhoenix’s comment):
https://www.cemetech.net/forum/viewtopic.php?t=9452&view=previous&sid=b6798d59690188fe6aabbb9f068367cd

My first question is how I would do sin in ICE. I need it so I can find how much to increase the rays by (y+sinθ and x+cosθ) In the documentation it says sin( returns root sin? The equation for it is 255*sin(2/256*2*π ) I’m not really sure how that works or what is happening with it at all. How would I get regular sin from it?

Well, the sin() function of ICE return a fixed point number - That is the value of sin multiplied by ~256. That mean that 1.0 =~256, -1.0=~-256.

Since float would be prohibitely slow, integer only computation are much better - you only have to reserve fractionnal bit in your integer to have a fractionnal part (in the sin case, 8 bit are reserved to fractionnal).

Keep in mind that you'll need to take care of possible overflow, and that multiplication of fixed point number is kinda different from multiplying integer since you need to take in account to fractionnal part :

Multipliying two 8.8 fixed point give you a 16.16 fixed point number for example, that you'll need to shift right 8 times to get a 16.8

As for the value inside, it is simply a correspondance between integer and real value, as pi/2 = 64 and so full circle or 2pi is equivalent to 256

Ok that makes sense thanks for helping so fast that was like 1 min haha

The raycast is mostly working except for one part that I don’t understand. So I have a list of sin(0), sin(10), sin(20) ... cos(0), cos(10), cos(20) ect. all of these are multiplied by 1,000 and made an int because ICE doesn’t work with floats. All of the list stuff works (I tested for a while with everything). I have 4 variables 2 are the real points (testx, testy) they test if there is a wall. the others have the remainder of the sin (remax, remay) As an example: if the angle of the ray is 0 degrees the sin would be 0 (increasing the y by 0) and the cos would be 1 (increasing the x by 1) since everything is times 1,000 it would be remax+1000->remax and remay+0->remay so the ray should not move at all on the y axis. But for me it jumps up and down. If I get rid of the

Code:

Everything works perfectly (but if there would be a different angle that would go down, it wouldn’t work at all) is there something I’m missing with comparing negative numbers in ICE?

If my explanation wasn’t understandable for you, just ask for some more code

IIRC, ICE doesn't have a concept of negative numbers. -1 is treated the same as 16777215, which works fine for addition and multiplication but not comparison. So, in order to compare two numbers which might or might not be negative, you'll have to add some large constant to them.

Wow the raycast part now works 100% that’s insane. Also it crazy fast right for what it does even though I haven’t optimized at all. Also it’s just a bit over 1000 bytes (or whatever it shows in the memory for the ti 84+ CE) now I can start on the actual drawing

Cool! Do you have any screenshots of it in action?

It’s a bit hard for me to get screenshots because my pc isn’t a Mac and I don’t feel like using tilp or that stuff for Linux but I’ll be able to get screenshots in a bit (: Also how do you do gif screenshots?

Wut? That won't change anything, you can't screenshot the calc while it's running ASM programs.
The only way would be to screenshot/record CEmu running your program.

Oh I’ll have to try that when I get out of school. That will be really cool if it works.

Before I can get home I have a bunch of free time so I can work on the program a bit. Is there any way to simplify an ICE if statement like in basic? For an example in basic:

Code:

Optimizes to

Code:

I already tried to do the exact same thing in ICE but weird things happen

In ICE this really isn't much of an optimization - it's faster in BASIC because it takes time for the parser to read each token, which basically means that whatever has the least number of tokens will be fastest. In ICE, however, all the parsing is done at compile time, so the number of tokens doesn't matter. It would probably be slower overall due to the multiplication, which is negligible in TI-BASIC due to the huge parser overhead but makes a difference in ICE where that overhead doesn't exit.

Im having problems with CEmu and installing it on linux /: Once I polish the raycast, is it fine if I send the asm program then someone can run it and post screenshots/recordings?

I think you can write: D+20*(K=25)→D

To install cemu try this: sudo apt install cemu

CEmu isn't packaged on any Debian variant, AFAIK, so that won't work.

The actual download instructions are here, though presumably you've already seen that.

I think I was able to install it but I cant find how to launch it? I cant find it on my pc at all.

I’ll probably just end up taking a video of my calculator screen until I can figure that out. After a little bit of work I got it rendering the 3D area onto the screen. It’s insane, the FPS is crazy for no optimization, and it freaking 3D

So it’s going along pretty well. The FOV right is 80 degrees (a ray every 10 degrees) and I plan on having an option to change the degree/ray to 5 (16 rays) and 1 (80 rays whoa) so that will be fun the random looking numbers at the top by the map are how long each ray is and the red things are the rays (of course). Right now the colors being displayed are not great because of how weird the ICE color pallet is. I was also able to add scaling and a floor pretty fast. Here is a checklist that I made because I was bored:

Program ideas
1. And gray-scale colors to the rendering
2. Info about the degree/ray
3. Add the ability to turn off ray drawing/other debug stuff
4. Add a sprite character for map
5. Add ceilings and floors (with option to turn on/off)
6. Edges for render region on/off

Things I'm working on right now
1. Add FPS counter
2. Have the option to switch from 10 to 5 to 1 degree rotation/ray

Ideas that are finished
1. Make you go the direction you are facing if pressing the up arrow
2. Remap the keys

Way later ideas
1. Add a shading editor
2. Make it into an actual game
3. Add wire-frame option
4. Map maker/editor

Optimization ideas
1. Make the list just shift down/up when turning and only have to calculate the one new angle (insane and will make everything sooooo fast)
2. Change all small if statements to faster version (more testing needed)

The program ideas aren’t really in a specific order besides me thinking of them at that time. If there is anything else I should add, that would be cool.

Ok I was able to take a video and put it on imgur so you can see it (:

There are some weird bits on the edges and when it moves there like a shadow before its gone, that's just the gif. Here is a like to the original video if you want to see what it really looks like:
https://imgur.com/VrdyKds.mp4

I have been working on the FPS tracker. Right now it displays how many frames went by in 1 second:

Code:

This way would only display every second so it wasn't super pretty. While I was typing out this post I figured out that I could just do

Code:

I still wanted to keep this post because it might be an answer for someone

Anyway, I got CEmu working by using wine to install/run the windows version and it works perfectly so ill be able to record better

Here is the updated list of things:

Program ideas
1. And gray-scale colors to the rendering
2. Info about the degree/ray
3. Add the ability to turn off ray drawing/other debug stuff
4. Add a sprite character for map
5. Add ceilings and floors (with option to turn on/off)
6. Edges for render region on/off

Things I'm working on right now
1. Have the option to switch from 10 to 5 to 1 degree rotation/ray
2. Make a pause menu for options

Ideas that are finished
1. Make you go the direction you are facing if pressing the up arrow
2. Remap the keys
3. Add FPS counter
4. Add color to the floor to add to the 3D ness (Looks a bit weird so not totally done but idk)

Way later ideas
1. Add a shading editor
2. Make it into an actual game
3. Add wire-frame option
4. Map maker/editor

Optimization ideas
1. Make the list just shift down/up when turning and only have to calculate the one new angle (insane and will make everything sooooo fast)


Also I tested the optimization idea of #2 and the smaller if statements (X+1×(X=1)→X ) are actually a good amount slower then an expanded one. Also the FPS counter right now is a F/100ms so I can compare more easily and it looks cooler One last thing I did today was improve the scaling (so now it isn't so blocky) and I made the program a bit less chonky (2000 when not compiled, 2200 when compiled)