Hmm, this got me thinking, could we get an augmented reality thing going using this program, an Arduino, and a camera? The FPS would be awful, but would it still be possible?

Pokémon Go on a CE!

Probably not, as a fully featured program.
The normal graphics (without augmented reality) would have to probably scaled down to pretty much 16x16, and the augmented reality would defy your lowest expectations.

EDIT: and you would have to do some serious processing on the Arduino. I don't know how much storage they have, but it may exceed it.

<salty c4>
This man has bone animation on a calculator and i cant do it correctly in opengl >_>
</salty c4>

PT_: 20 polygons are no issue for the engine

And yeah I don't think VR is such a good idea.

So it's been quite some time. There has been a few optimization, and some new exiciting feature : the engine now is able to handle alpha transparency. That come with a new texture converter.

The code isn't still up in the github, because I want to fix a few thing first and add more modularity, but have a nice screenshot :



You can mainly notice the effect in the hair, and in the clothing.

Even more fluffy :

Looks amazing man! Very spiffy.

Thanks !

About some other news :

I am currently planning to be able to switch vertex/geometry/pixel shader per triangles batch basis, to be able to use wide range of effects where it is needed and not on the whole scene. Playing with pipeline state is so much fun (read : painful )

About alpha transparency texture performance : I am currently able to filter such pixel at more than half the rate as plain texture pixel. (ie, 55.5 cycles/pixel vs 29.5 cycles/pixel). Didn't expected so much performance from here !

Still, it is quite slow for fullscreen rendering, needing respectively 88ms and 47.5ms. The texture algorithm also suffer from quite high overhead which will need to be reduced to be usefull. I'll be more than delighted if I could do a whole screen rendering in about 150ms (or 6.6fps) with I think 50ms for pixel, 50ms for vertex and 50ms for the rest. I am not there yet, but I'll try
So much thing to compute and so little time haha.

EDIT :

So, a few more screenshot from (almost) recent testing :


A test using the general interpolation triangle rasterization to interpolate lightning intensities instead of texturing. Along side with vertex lighting, it does look quite good (altough it is just a tiny bit faster than plain texturing sadly)


Pratical use of transparency !

That's incredibly impressive! Is 47.5ms the rendering time for that bottom environment with transparency? If so, I have to say that 20FPS before adding game logic is really quite reasonable for a calculator game, and I can't wait to see where this will go.

Looks awesome!

It is unfortunate about the fillrate on the CE with regards to fullscreen performance for anything that needs even minimal calcs per pixel - that being said, this is significantly pushing the limits of what's possible.

Do you have compiled file of the demo? I cant get the code to compile unfortunately. The build bat file seems to just hang.

There are lots of examples of this on TI-Planet. I'm not sure if they're the same, but I'll check.


EDIT: Here's a link to the page on TI-Planet. There are like 20 examples. I think all of them are by TheMachine02, but I don't know how updated they are.

I know this is probably a silly question, but where is the actual program that runs the simulation? I cannot find it on the GitHub page TheMachine02 linked to.

It's not there, you need to build it yourself I believe. You can check out jcgter's link he provided

I really love this project! The demo programs are really fun to run! Keep it up.

That looks REALLY COOL!

Also, some questions. Since you're doing this in ez80, would it be similar doing this in C, or completely different?
In addition to that, people can just change the sprites and the control for anything, right? Or do they just use this as a template? (***jcgter777 is thinking about RubEX and AoCE)

1) No, the two languages are completely different on that front. (AFAIK)
2) AoCE and RubEX are not going to be using this engine (probably). There are numerous optimizations you can make when you are only pointing in one direction. They would never be able to reach a playable speed with a generalized engine. (And it sort of defeats the point of those programs).

There is compiled demo on the github in the bin/ folder, with data appv, TEST program are what you looking for Don't forget to send appv though, right now TEST use london0 to london2 ; TEST1 use SUZAN0 and SUZAN1 and lastly TEST2 use FRAN0 to FRAN3.

For .bat to build, you'll need to have spasm and convhex somewhere on the master folder.

It wouldn't actually so hard to be able to have C handle it as external library, but I use some nasty asm trickery that won't play fine with C right now for speed purpose. You can definitly change everything ! It is a general purpose 3D engine, which can almost handle everything you throw at him ! The example provided are just a glimpse of what is possible.

About AoCE, my engine definitly shouldn't be used to do that As for RubEX, I would be less categorical as the workload wouldn't be so hard on the CPU anyway.

This is by far the coolest thing on a calculator that I've ever seen. (Not including Cesium ). I would love to mess around and play with kind of stuff. Though I don't think I'm that advanced... so, for now, I'll have to stick with watching those gifs.

You can just use the examples from the source, just transfer them to your calc and start playing. See the post above yours.

*bump* I've noticed there hasn't been any status update on this on Cemetech, TI Planet, nor GitHub in quite some time, do you plan to work on this anymore? I'd love to see this at least as a V1 release!

I do plan to work on this, but my progress has been really slow downed by works. So yeah, lot of stuff, not many time as always.