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 1 Guest are viewing this topic.

DJ Omnimaga

By too big, do you mean you have hit the 64 KB code limit on the 68K calcs? I hope that the project isn't 100% dependent on more people joining, though, since the 68K community is quiet nowadays. Good luck with whatever you decide.

catastropher

Quote from: DJ Omnimaga on August 17, 2015, 04:00:07 pm
By too big, do you mean you have hit the 64 KB code limit on the 68K calcs?


Well we weren't close to hitting the 64k limit yet, but the library will keep growing and by the time you add in client code, it may be too much. In addition, if there are multiple programs using X3D there will be a lot of wasted space. The level editor posted a month ago was already over  20k O.O

Quote from: DJ Omnimaga on August 17, 2015, 04:00:07 pm
I hope that the project isn't 100% dependent on more people joining, though, since the 68K community is quiet nowadays. Good luck with whatever you decide.


Don't worry, it isn't ;) My friend Jason is currently contributing when he can, so I'm not totally alone in working on it. I just want to open the door if anyone is interested since I'm a computer science tutor at school and I love helping people learn. Also, the goal is to support PC and the NSpire as well, so there will eventually be a need to port it :)
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Ah ok, good to hear. I wonder if there are chances of TI-84+CE support, since that calc can use C? It has 150 KB of user RAM and 3 MB of Flash.

catastropher

That may very well be possible :) The only thing is, X3D is specifically built for rendering in monochrome (which is how the engine renders things so quickly). The question is, would people be alright running a monochrome 3D game on a color device? Since X3D doesn't actually do any polygon filling, it's literally impossible to to have walls be different colors. But if people are interested, I'll take a look into it ;)
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

I would be fine with it. But of course you could simply just change the lines and background colors. What would be cool is some sort of FPS or maze game where the player is in a virtual reality and the lines would be green and background black.

Could lines have different colors in one stage by the way?

catastropher

That is an awesome idea! Indeed, the lines could be any color, even from room to room (I can add this functionality in, if you'd like). The only thing that can't change is the wall color, unless the calculator would be fast enough to handle polygon filling. I know that in the case of the 68k calcs, this isn't possible (if you've seen the topic on Omnimaga, I originally wanted X3D to be grayscale but it just wasn't fast enough).

Since I'm beginning a rewrite, I suppose it'd be a smart idea to add in support for the TI-84+-CE from the get-go. I wonder if GCC can retarget for it... right now the build is dependent on GCC. I may be able to have the source be somewhat compiler-independent though.
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Cool to hear. And yeah different line colors is what I meant. Also I made some mockups:


EDIT: Here are mockups:

TI-84+CE/Nspire



TI-84+CSE




That blue one would have the dark part of the gradient move up and down with the camera, to make it look like the horizon is darker. The CSE one was made 160x240 since the game would probably be too slow in 320x240 mode.

catastropher

Oooh that looks awesome! Ok, my mind is totally made up, X3D will definitely run on the NSpire and the TI-84+CSE :D It doesn't look like GCC retargets for it though, so I'll need to think about how to make the source compiler-independent (I'm currently using some GCC extensions in the code). Thanks for making the mockups, you have totally convinced me :)
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Actually, now that I remember, the CSE doesn't really support C as much as the CE, since it's a Z80 model. There is SDCC but it's probably not ideal like doing C on the TI-84+CE. Cemetech has a topic on how to program C on the ez80 TI-84+CE.

And glad to hear :walrii:

catastropher

So I've decided to not totally start over. Instead, I'm working on refactoring the existing codebase. Aside from that, the main thing I'm working on is collision for objects with the level. Different types of objects can have different collision behavior when hitting a wall:

  • Bounce - good for things like a bouncing ball

  • Slide along the wall - good for the camera, instead of abruptly stopping

  • Stop - motion stops, though gravity can still pull it down, if enabled



Of course, there will be a collision callback for custom behavior. This could be useful for e.g. exploding bullets that explode when they hit a wall. Collision is unfortunately kind of a complicated mess because an object can be partially in multiple rooms at once. In addition, the engine has to keep track of which rooms an object is in, which requires collision detection since moving from room to room is treated as a "collision" with a doorway (i.e. a portal between two segments). This is why in the editor screenshot I never actually leave the main room.

Anyway, I'll post again when I've made progress!
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Yay! Although restarting over can sometimes be necessary, IMHO I think that sometimes it's being overdone and the TI community has been plagued by this phenomenon ever since graphing calcs came into existence. People restart their projects from scratch over and over until they reach the point where they get bored of never progressing then call it quit. Escheron: Shadow over Rangaroth is one recent notable example (although it was revived recently as a downscaled game) and there are even some projects that got rebooted after they reached 99% completion.

Also regarding the objects, do you mean for example stuff that you stand next to? For example, would the bounce effect be used when you stand on some platform that makes you move up to reach the second or third floor? Modern FPSes got that and it's cool. I hope you can implement those features without too much hassle :)

catastropher

Quote from: DJ Omnimaga on August 21, 2015, 04:03:35 pm
Yay! Although restarting over can sometimes be necessary, IMHO I think that sometimes it's being overdone and the TI community has been plagued by this phenomenon ever since graphing calcs came into existence. People restart their projects from scratch over and over until they reach the point where they get bored of never progressing then call it quit. Escheron: Shadow over Rangaroth is one recent notable example (although it was revived recently as a downscaled game) and there are even some projects that got rebooted after they reached 99% completion.


I am sadly guilty of this... this is actually the 4th or 5th rewrite of X3D. The problem is I tend to quickly implement things without thinking of the overall design, which leads to really big problems once you start trying to build on top of it. The current history for X3D looks like this (ignoring 2011 - 2014):

  • First version (early February) - grayscale engine that was waaaaay too slow

  • Second version (late February - April) - monochrome line renderer that uses cubes (what was used to for the light bridge screenshot). Wasn't written to be a library

  • Third version (early May) - first attempt at making a library, stopped after a week

  • Fourth version (late May - mid July) - second attempt at making a static library, which uses the new prism engine (what powers the level editor)

  • Fifth version (early August - present) - current version that is a DLL, continuing where version 4 left off


The thing is, I've never worked on a project that is so complex and so math heavy, so it's taking me a while to figure out how to organize it. But, I think I'm finally getting the hang of it :)

Quote from: DJ Omnimaga on August 21, 2015, 04:03:35 pm
Also regarding the objects, do you mean for example stuff that you stand next to? For example, would the bounce effect be used when you stand on some platform that makes you move up to reach the second or third floor? Modern FPSes got that and it's cool. I hope you can implement those features without too much hassle :)


So, in X3D there are (perhaps I should say "will be") two types of objects. Static objects are objects that don't move and are part of the level, such as decorations, jump pads (like what you described), switches, etc. Dynamic objects are objects that can move, such as the camera, enemies, bullets, etc. The bounce effect I was talking about is when a dynamic object hits a wall and bounces off (think pong). However, making a jump pad would be quite easy - just create a collision event between the camera and the jump pad that sets the camera's vertical velocity. For dynamic objects, they can either be active or inactive.  When inactive, an object isn't processed at all (to cut down on lag). However, an object can be made active if e.g. the player sees it.

My goal is for X3D to be a very dynamic engine that the player can interact with. Thus, things like switches, doors, moving platforms, jump pads, teleporters, items that can be picked up, etc. will be very easy to create. Oh and btw, I got smoothly sliding along walls to work. Now on to moving between rooms!
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Wow I didn't know X3D started this long ago. O.O But yeah optimization problems can happen during projects or sometimes you take a break and you forget what the code did (mostly common with on-calc BASIC, though, which doesn't allow comments without running out of RAM). Some coders also starts larger projects but then gain extra experience in programming while their projects advances, so they find their old code messy and want to rewrite it.  It's a good thing that you started with smaller projects first by the way, since it's easier in our early programming days.

And thanks for explaining how objects work. Will objects be rendered and active only within a certain distance such as three rooms radius or will they go inactive as soon as they are out of viewing range (such as behind you)?

catastropher

Quote from: DJ Omnimaga on August 22, 2015, 01:39:47 am
Wow I didn't know X3D started this long ago. O.O

Haha yeah, the project idea has been floating around in my head for a while now :P I had posted about its early history over on omni several months ago (https://www.omnimaga.org/ti-68k-projects/descent-68kx3d)

Quote from: DJ Omnimaga on August 22, 2015, 01:39:47 am
But yeah optimization problems can happen during projects or sometimes you take a break and you forget what the code did (mostly common with on-calc BASIC, though, which doesn't allow comments without running out of RAM). Some coders also starts larger projects but then gain extra experience in programming while their projects advances, so they find their old code messy and want to rewrite it.  It's a good thing that you started with smaller projects first by the way, since it's easier in our early programming days.

It sounds very difficult to write in BASIC O.O Also yeah, it's a good thing I didn't start out by trying to write a library. I would never have accomplished anything!

Quote from: DJ Omnimaga on August 22, 2015, 01:39:47 am
And thanks for explaining how objects work. Will objects be rendered and active only within a certain distance such as three rooms radius or will they go inactive as soon as they are out of viewing range (such as behind you)?

That's a very good question. I think object behavior should be left to the "client", though I'll provide a few pre-programmed options to choose from for when an object becomes deactivated such as:

  • The object is too far away from the camera

  • There is no direct line of sight between the object and the camera

  • The camera is in a different room

  • There are too many active objects


In addition, the programmer can choose when to activate/deactivate an object when e.g. a switch has been activated (useful for doors/elevators). Btw, I wanted to say thanks for the encouragement and interest in the project, it's really been inspiring me to continue working on it! :D Also thanks for asking questions like this, it's helping me think about how the engine will be organized! Oh, and collision detection is working for the camera, so now it can move between rooms! I'll post a screenshot later! :)
Creator of X3D, a 3D portal rendering game engine for Nspire, 68k, and PC

DJ Omnimaga

Ah right I missed the part saying it started in 2011 in the original post. Your post on Omni was made months after the split and when I left so I didn't pay attention there as much afterward. As for BASIC it's not that hard to use it on-calc, but once you manage to get used to doing it on the computer it's hard to come back. Sometimes you have no choice if you want to test programs fast, though (eg the 84+CE lacks a free emulator and I find it kinda tedious to send programs to my calc everytime I update my code on SourceCoder editor.)

And I see. More options for objects is definitively good. Actually some of those could allow someone to port Slender to X3D (although it would be weird without sound)

Powered by EzPortal