Our robot still has yet to shoot. At least our drivetrain will be great this year - shifting 6 CIM with six 6" diameter 2" wide wheels, all connected with polycord. I don't have a picture of this year's robot, but here's one from last year - we are using similar construction techniques.
I think this thread is pointless, as the new version will be ready when it is ready. It is already clear that everyone wants a new version of Ndless, and making a poll about it is not going to make the update arrive any sooner.
Firefox user here. I have never had a problem with the size of the user interface - the tabs are overlaid on the title bar just like Chrome. I prefer it because of the values of Mozilla as opposed to Google.
I was convinced this effect could be made faster, and after a lot of careful thought and crazy tricks, I managed to bump up the FPS: from 14.3 to 18.5, an improvement of about 30%! Again, it is running at 15MHz. It may look slightly different, as I had to rotate the texture up and right by one pixel per frame (rather than down and right) due to complications of the immensely aggressive optimization. I'll attach the source to this post, but be warned that there's a still a bug that I haven't had the time to hunt down which crashes the calculator with fair frequency upon exiting. But here's a gif, proving that it does indeed work:
Spoiler For Oh, and did I mention...:
... that that's just the pure Axe version?
As is always the case for assembly, and is especially the case for really specific, concise algorithms, if you know what you're doing you can get big performance gains over a compiled language. Re-coding only the rendering core in just as (if not more) aggressively optimized assembly, I registered a huge boost in FPS: 18.5 to 44, an improvement of about 140% on my pure Axe version and 200% on the existing assembly core version! The source for this will be attached as well, and luckily this one is 100% stable, so play with it all you want! Here's a gif again, showing it off, although keep in mind that it's actually rendering about twice as many frames as the gif captured:
Spoiler For Wait a second...:
... why does that gif say 6MHz and load effects so slowly? Because it is 6MHz!
The true 15MHz FPS for the version with the assembly core is a stupidly high 107! This is with no pre-rendering of frames or any such cheating, every frame is rendered pixel-by-pixel as always. So the total performance markup on the original 14.3 FPS comes to about 650%. You can try it for yourself by simply un-commenting the Full in the setup part of the assembly version source. And although it doesn't even capture a quarter of the frames rendered and the original effects are all but impossible to discern, here's a gif:
Beat that.
Do you think this could be made into a mode 7 engine?
Where is cheating coming into this? I don't understand how pictures would further enable it when you already have a device from which you can store and recall information. I think it is hypocritical to refrain from circumventing Casio's restrictions when we are doing the same with the Nspire.
Anyways, if there is information on the 3-bit file format available, I could probably cobble something together. By the way, that Zelda map is looking good.
You should switch to writing bytes, not words, and then since pixels are 4 bits, have two different routines, one byte aligned and the other not which you choose when the x coordinate is even or odd respectively. Alternatively, if you need this to be really fast, you can set the LCD controller to 8 bits per pixel.
The main reason I think is because ndless also opens the way to cheating. Allowing ndless could cause the nspire becoming disallowed on exams and TI would lose a part of their income.
It's already happened, and I don't see the calculator being banned from any tests.
Show Posts
