Powder Game

[AngelFish]

Eiyeron, please don't troll. The Prizm, while not as fast as some of the other Casio calculators, is still faster than all of the 83 and 84+ series calculators from TI. Furthermore, the Prizm is more than fast enough to run some impressive projects, especially since it can be overclocked.

[JosJuice]

I guess ASM/C?

I'd say you be guessing right. On the Prizm there are so many more possibilities for a Powder Game port with the hi-res color screen, large memory, and fast proc. I can hardly wait

FAST PROC! Let me laugh! The Cowards form Casio do as crappy work as TI, specially slowing down the calculators! I'm sick of the priszm performances! BUt In fx-9860, with or without cpuspeed... Wow

By this, do you mean the actual CPU speed, or the speed at which math commands and such execute? Both are dependent on the CPU, but the latter also depends on Casio's OS, which doesn't have much to do with what programs can be written. I do not believe that the clock speed has decreased, but the math may have gotten slower - I'm not sure since I don't have an fx-9860.

Eiyeron, please don't troll. The Prizm, while not as fast as some of the other Casio calculators, is still faster than all of the 83 and 84+ series calculators from TI. Furthermore, the Prizm is more than fast enough to run some impressive projects, especially since it can be overclocked.

The Prizm definitely has a better processor than TI's calculators (excluding the Nspire, which is slightly faster but doesn't allow machine code execution), and if it's possible to overclock them, we'll have even more possibilities. Considering what can be done with 15MHz or even 6MHz, it will definitely be possible to create many impressive programs and games for the Prizm, although the processor speed is quite a bit slower than modern devices that aren't calcs. However, I do not agree that Eiyeron's comment was trolling. Everyone has different opinions, and calling people/comments trolls/trolling is not the best way to be friendly.

[Eiyeron]

I dont want to troll, but revocate the casio's decisions! Okay, thre are calculators, but jow could they (both Casio and TI) ignoring a big part of market?
http://www.planet-casio.com/files/forums/VitesseFonctionsBasicCasio-9648.zip There is a benchmark sheet...

[DJ Omnimaga]

Eiyeron by the way in the past we banned a member who kept bashing TI and Casio calcs and we almost had to do with someone who was doing the same with the TI-83+ (he was a TI-89 fanboy). You may want to be careful about what you say about the Prizm.

Plus the Prizm problem is not that it's by itself slow, it's that Casio failed epically hard at creating the BASIC language included in the calculator, even more than TI. I'm sure anybody in the community could write a BASIC interpreter or semi-interpreter that would solve most of the display speed issues currently present on the calculator. Else, someone could port Axe Parser for example.

Just because the Prizm BASIC language sucks doesn't mean the entire calculator do. The language was just poorly programmed. Look at games like Obliterate written in C or the Insight add-in. They get about 20 frames per second, even if in one of the app there are 100 particles moving around at once.

Also I doubt Casio or TI would listen to us, because their philosophy is that calculators are for math, not gaming, and about only 1% of the students will use their calculator for gaming, meaning their market share for gamers is probably around 1%.

I'M pretty sure the Prizm could achieve Doom. It would probably just run slightly slower than the TI-Nspire counterpart.

[t0xic_kitt3n]

Yes, DOOM is quite possible, and it will look a heck of a lot better on the prizm, compared to the nspire port. Remember, DOOM was written to run on 386 processors, which are around 33 mhz if I recall correctly.

[Eiyeron]

So.. Powder Game? I like this game. Do you want to make this too in java? :p
(I want too to apologize me to make some stupid noise here)

[DJ Omnimaga]

It's ok. Just try to make sure to not say stuff that could start a calc war or something like that one HP guy that came here a while ago.

firstly, that was a bit of a necropost, and secondly, if you had read through the thread, you would have seen that the project has been discontinued.

6 days, necropost... mhm yes.
Sorry

Actually it was not 6 days, but rather 67

On a side note would Nspire Lua be good enough for such Powder game?

[t0xic_kitt3n]

IDK about Lua, due to the number of calculations and particles.

[boot2490]

The only thing that was fun in the originals was blowing stuff up and burning stuff.
I suggest you ty to make explosions as realistic as possible, conforming to real life not the games.

[AngelFish]

Sorry, but this project is dead (and explosions were never planned in the port anyway because they're too slow to compute for z80).

[z80man]

The only thing that was fun in the originals was blowing stuff up and burning stuff.
I suggest you ty to make explosions as realistic as possible, conforming to real life not the games.

I was earlier going over the possibilities of a Prizm port of powder game as Qwerty has already planned. Part of the problem is that realistic physics are doable processor wise if fixed floats are used but the ram is just too small. In order to have physics as realistic as the game powder toy which I believe is the most realistic powder game, 20 bytes of data is required for each particle. This would be a 1 byte identifier, 3 byte particle specific data field (required for longword alignment), 8 byte floating point velocity vector (x float and y float), 4 byte temperature float, and 4 byte pressure float. If the entire screen is used about 1.65 Mb of ram is required just for data while the Prizm's heap is only 128 kb. In additional ram there is the backup VRAM at 165kb, the g3a stack at 512 kb but not all is available, and the OS stack also at 512 kb but I'd be very careful with that space as OS routines have the ability to eat that area up.

[AngelFish]

You can compress that data significantly. Let's assume 1 byte for the identifier (you'd actually need fewer bits) with 1 byte particle data and a 256x256 screen (you need some portion for a menu). That means you're down to 1 byte each for the x and y variables (integers are more efficient representations of integers than floating points) and you can skip the temperature variable because it doesn't exist in the canonical version. What's left is the pressure, which can be placed in a 1 byte variable. Thus, you have 5 bytes, which should probably be rounded out to 6 bytes with an extra "data" byte after the ID. That's only 384 KB.

[Freyaday]

You can compress that data significantly. Let's assume 1 byte for the identifier (you'd actually need fewer bits) with 1 byte particle data and a 256x256 screen (you need some portion for a menu). That means you're down to 1 byte each for the x and y variables (integers are more efficient representations of integers than floating points) and you can skip the temperature variable because it doesn't exist in the canonical version. What's left is the pressure, which can be placed in a 1 byte variable. Thus, you have 5 bytes, which should probably be rounded out to 6 bytes with an extra "data" byte after the ID. That's only 384 KB.

That temperature variable is actually really useful. It's what allows stuff like fire! And convection! And Stuff!

[AngelFish]

Nope. All of that is handled through the particle ID and the pressure data.

[Freyaday]

Nope. All of that is handled through the particle ID and the pressure data.

Oh ok!