The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

X3D - A 3D engine for TI68k & Nspire Calculators

Started by catastropher, June 27, 2015, 02:37:43 am

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

DJ Omnimaga

Quote from: Vogtinator on April 19, 2016, 04:24:58 am
QuoteLol, imagine if Nspire C had linking capabilities

It has: https://hackspire.unsads.com/index.php/Syscalls#NavNet
Vogtinator aah thanks. I was still under the impression that the TI-Nspire USB protocol was still something very cryptic for most programmers to even bother adding linked play to their games or the like.

Quote from: catastropher on April 19, 2016, 04:34:21 am
Quote from: Vogtinator on April 19, 2016, 04:24:58 am
That looks great! Now add shadows and ambient occlusion to make it look even better :P

haha While I can't do either of those things, I have figured out a way to do gouraud shading with textures at a very low cost... hopefully I'll add that in once I get it fast enough! :D
On an unrelated note: Do you think the engine would run much faster if it was used only to render a flat surface made of various textures? If that's the case with a large enough map, then could the engine be used as some sort of fake mode-7 graphics for an F-Zero or Mario Kart clone?

ben_g

Quote from: DJ Omnimaga on April 19, 2016, 06:51:52 am
Quote from: catastropher on April 19, 2016, 04:34:21 am
Quote from: Vogtinator on April 19, 2016, 04:24:58 am
That looks great! Now add shadows and ambient occlusion to make it look even better :P

haha While I can't do either of those things, I have figured out a way to do gouraud shading with textures at a very low cost... hopefully I'll add that in once I get it fast enough! :D
On an unrelated note: Do you think the engine would run much faster if it was used only to render a flat surface made of various textures? If that's the case with a large enough map, then could the engine be used as some sort of fake mode-7 graphics for an F-Zero or Mario Kart clone?

I think using actual mode 7 for that would be faster and better.

DJ Omnimaga

Yeah I know, but maybe catastropher isn't willing to make an actual Mode 7 engine. :P

Vogtinator

Quote from: catastropher on April 19, 2016, 04:34:21 am
Quote from: Vogtinator on April 19, 2016, 04:24:58 am
That looks great! Now add shadows and ambient occlusion to make it look even better :P

haha While I can't do either of those things, I have figured out a way to do gouraud shading with textures at a very low cost... hopefully I'll add that in once I get it fast enough! :D


Gouraud shading is using interpolated vertex normals for lighting, isn't it? If so, definitely awesome!

catastropher

Quote from: DJ Omnimaga on April 19, 2016, 06:57:48 am
Yeah I know, but maybe catastropher isn't willing to make an actual Mode 7 engine. :P

Hmmm.... well you could probably just draw a really big polygon with perspective-correct texture mapping on :P

Quote from: Vogtinator on April 19, 2016, 03:10:11 pm
Gouraud shading is using interpolated vertex normals for lighting, isn't it? If so, definitely awesome!

Indeed it is! I actually got lighting/dithering to work faster than texture mapping for colored walls. The tricky part is getting that to work with textures. Luckily, I think I've found a solution that involves several huge color tables haha

Right now, my biggest bottleneck is that I'm doing perspective-correct texture mapping for every pixel. I'll likely do what Descent did and only do it once every 16 or 32 pixels. Curse you ARM for not having a division instruction!
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

Vogtinator

Quote from: catastropher on April 19, 2016, 03:42:18 pm
Quote from: Vogtinator on April 19, 2016, 03:10:11 pm
Gouraud shading is using interpolated vertex normals for lighting, isn't it? If so, definitely awesome!

Indeed it is! I actually got lighting/dithering to work faster than texture mapping for colored walls. The tricky part is getting that to work with textures. Luckily, I think I've found a solution that involves several huge color tables haha

I experimented a bit with nGL and found that the caches (I and D) are your biggest friends and enemys. Especially on the Nspire, RAM is horribly slow, so huge tables will cause more slowdowns than speedups. Still: Do many benchmarks and profile everything!

QuoteRight now, my biggest bottleneck is that I'm doing perspective-correct texture mapping for every pixel. I'll likely do what Descent did and only do it once every 16 or 32 pixels. Curse you ARM for not having a division instruction!


I'm only doing affine mapping in nGL and it doesn't really make a difference when playing.

catastropher

Quote from: Vogtinator on April 19, 2016, 04:16:59 pm
I experimented a bit with nGL and found that the caches (I and D) are your biggest friends and enemys. Especially on the Nspire, RAM is horribly slow, so huge tables will cause more slowdowns than speedups. Still: Do many benchmarks and profile everything!

Thanks for the suggestion! I actually didn't realize the Nspire has cache... oops haha I've changed my texture format to be indexes into a color table (8 bits, 4 bits, or 1 bit). Hopefully that'll increase the chance of a texture fitting in cache! I may also implement mipmapping and reduce the resolution of the textures (right now I'm using 128x128... perhaps 64x64 or 32x32 will work better). Are there instructions for the emulator somewhere? I never could get it to work for some reason so I've been testing on the real device. Also, how would I go about profiling things?

Quote from: Vogtinator on April 19, 2016, 04:16:59 pm
I'm only doing affine mapping in nGL and it doesn't really make a difference when playing.

Hmmm... I implemented perspective correction for every 32 pixels. I'll have to see how much of a hit on performance that is.

Thank for so much for your help! :D
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

Vogtinator

April 20, 2016, 04:42:32 pm #202 Last Edit: April 20, 2016, 04:47:03 pm by Vogtinator
Quote from: catastropher on April 20, 2016, 04:35:07 pm
Quote from: Vogtinator on April 19, 2016, 04:16:59 pm
I experimented a bit with nGL and found that the caches (I and D) are your biggest friends and enemys. Especially on the Nspire, RAM is horribly slow, so huge tables will cause more slowdowns than speedups. Still: Do many benchmarks and profile everything!

Thanks for the suggestion! I actually didn't realize the Nspire has cache... oops haha I've changed my texture format to be indexes into a color table (8 bits, 4 bits, or 1 bit). Hopefully that'll increase the chance of a texture fitting in cache! I may also implement mipmapping and reduce the resolution of the textures (right now I'm using 128x128... perhaps 64x64 or 32x32 will work better).

Maybe, but I'd expect that mipmapping might slow it down.

QuoteAre there instructions for the emulator somewhere? I never could get it to work for some reason so I've been testing on the real device.

https://github.com/nspire-emus/firebird/wiki/First-Time-Setup
Keep in mind that the emulation is not cycle accurate, it's actually not even close.

QuoteAlso, how would I go about profiling things?

Either manually by putting some output into your code or by running it through a profiler such as gprof or valgrind's cachegrind on x86 or ARM.

DJ Omnimaga

I think 64x64 textures would be fine. Maybe even 32x32 for stuff that don't need as much details. Would it be easy to allow textures to be any of the two size?

catastropher

Quote from: Vogtinator on April 20, 2016, 04:42:32 pm
Maybe, but I'd expect that mipmapping might slow it down.

Ok, perhaps I'll give it a try later on just in case. For now though, I've resized all the textures to be 64x64 or less.

Quote from: Vogtinator on April 20, 2016, 04:42:32 pm
Keep in mind that the emulation is not cycle accurate, it's actually not even close.

Thanks! :D

Quote from: Vogtinator on April 20, 2016, 04:42:32 pm
Either manually by putting some output into your code or by running it through a profiler such as gprof or valgrind's cachegrind on x86 or ARM.

Awesome, I'll give this a try!

Quote from: DJ Omnimaga on April 20, 2016, 11:36:58 pm
I think 64x64 textures would be fine. Maybe even 32x32 for stuff that don't need as much details. Would it be easy to allow textures to be any of the two size?

Indeed, in fact you can have any texture that is a power of 2 in size. The nice thing about powers of 2 is they allow for easy repeated textures (like the floor tile) because [x mod (2^N)] is the same as [x & (2^N - 1)] (it's awesome because we can use logical 'and' instead of modulus!)

If anyone would like to try a buggy demo that is almost certain to crash your calculator, I have attached it to this post! :D

Note: there are numerous bugs/memory leaks, so run at your own risk!

New Features

       
  • Perspective correct texture mapping (performed every 32 pixels)

  •    
  • Repeated textures

  •    
  • More accurate scan-conversion/texture mapping

  •    
  • A new portal-themed texture (see if you can find it!)

  •    
  • Embedded textures stored into the executable

  •    
  • Indexed textures (8 bit or 4 bit)

  •    
  • Numerous performance improvements

Controls

       
  • 7 - forwards

  •    
  • 4 - backwards

  •    
  • keypad - turning

  •    
  • esc - quit

Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Hm a demo. I wonder if it would work on the emulator, because my Nspire CX was never stable to begin with. :P But I'm glad to see this is coming along nicely. :)

Does the engine still support platforms and objects that can move? What about shooting portals?

catastropher

Quote from: DJ Omnimaga on April 22, 2016, 05:15:45 am
Hm a demo. I wonder if it would work on the emulator, because my Nspire CX was never stable to begin with. :P But I'm glad to see this is coming along nicely. :)

Well hopefully it'll run on the real device (the only time it seems to crash is when you quit). Hopefully it'll work on the emulator as well! And thanks!

Quote from: DJ Omnimaga on April 22, 2016, 05:15:45 am
Does the engine still support platforms and objects that can move? What about shooting portals?

It'd make for a very lame game of Portal if it didn't support any of those things :P haha For right now, portals are disabled because their implementation needs to change now that the engine uses z-buffering. In the next few weeks I'll hopefully get that working again though! You'd be surprised how much it takes to create a game engine... I don't even want to think about how much of my life I've spent on this :P
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Yeah I was asking, because for some reasons, my Nspire CX always seemed to crash more than usual and that started long before I first tried Ndless for the CX. For example, PicoDrive (Sega Genesis emulator) won't run on my calc while it runs on all others or close.

And yeah I was wondering since the portals weren't listed in the features list for the demo. :P Good luck implementing those. :)

catastropher

Hi everyone! I'm happy to announce the most recent changes:

       
  • Portals are fixed

  •    
  • Numerous rendering glitches are fixed

  •    
  • It's now possible to attach doorways/windows to a wall without it taking up the entire face (before two rooms had to entirely share a face)

  •    
  • The first working doors were implemented!

Here's a screenshot (I was lazy and reused the wood texture for the doors):
Spoiler: ShowHide



As you can see, it's possible to have doors that open up and down, as well as side to side. Actually, a door can open along any axis so you could have slanted doors as well. Interestingly enough, a door is actually just a special room that can close haha
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Darn this looks on-par with Playstation 1 graphics. Nice job. Also some doors should use wood or wall textures and be secret passages. :P

Powered by EzPortal