I don't think it should slow it down significantly, since its only a single multiplication for each ray, and you can prerender the cosine functions before you start the simulation.
Yikes, i just had this do horrible things. set Y1=e^(X^2), Y2=nDeriv(Y1,X,X), Y3=nDeriv(Y2,X,X), Y4=nDeriv(Y3,X,X), and Y5=nDeriv(Y4,X,X). Then on the homescreen do Y5(0). I got a RESETING... message. I promptly pulled my batteries, and put them back in.... Grabage Collecting I only lost a small test program in archive and RAM, and was able to replicate it several times with fresh RAM clears. Whats going on??
Haha thats epic ^^ It also turns out if you take really sharp noises like glass breaking and slow them down over 9000 times, and add a bit of echo, it can turn really creepy
Yes this is the memory issue of the calculator, and cannot be bypassed in programs because it is a hardware issue. And with a game of this size, its understandable. The first thing you can do is compile it for MirageOS, since it does not have the limit and gives you any ammount of data as you need. After that stops working (ie: giving you ram clears), you will *need* to either switch to App, or some other method of storing your program. There is no way around it.
What you guys are noticing is the 'fishbowl effect', and can be remedied by multiplying the length of a cast ray by the cosine of the angle of the ray relative to the direction you are facing. But it looks awesome and fast! How exactly are you drawing the dithered walls so fast? Is it greyscale? because it doesn't look to be alternating
Show Posts
lol i fail
I only lost a small test program in archive and RAM, and was able to replicate it several times with fresh RAM clears. Whats going on??
Well glad you got the physics to work anyway 
