Earlier this year I posted on Omnimaga about X3D, my 3D engine for the 68k calcs. After a month hiatus for health reasons, I resumed work on it in May :D Some of you may recall the dazzling light bridge from earlier this year:
(https://img.ourl.ca/X3D%20BRIDGE.GIF)
Currently, I am in the process of rewriting the engine to support more complex geometry. It's been a long and slow process (I'm currently interning full time as a software engineer), but I've started to make some progress. The last version had levels which were constructed of interconnected cubes. The player could walk around inside the resulting structure, which proved to be very efficient. However, my whole goal of starting X3D was to get Descent to run on the 68k calcs, and many rooms in Descent are constructed of 20 or more cubes, which is just too much to handle. So, this new version will allow levels to be constructed of prisms instead of just cubes. What do I mean by prisms? Here's an example of an octagonal prism:
(https://img.ourl.ca/oct1.png)(https://img.ourl.ca/oct2.png)
The idea is you have two bases, each with the same number of points. However, the bases can be stretched, skewed, and rotated, so long as the resultant 3D shape is convex. My ultimate goal for Descent 68k is to merge the cubes in complex rooms into large convex prisms. This is several times more efficient to render than the same room partitioned into cubes.
So far, I have created a new clipping algorithm that clips prisms against a 2D polygon. A fast algorithm for this is crucial for a portal renderer like X3D. So far so good!
(https://img.ourl.ca/oct3.png)
Anyway, this time around, it's going to have a lot of cool features. I'm hoping to get some people involved on the project or at least make some games with it once complete (it will be a TIGCC/GCC4TI C library). Let me know if you're interested!
Holy cow thats impressive. This looks great. Maybe we'll get some cool 3d stuff.
Hey thanks! I may even write a scaled down version in Z80 assembly if I can get it fast enough. Unlike most 3D renderers for the calculators, X3D only ever draws lines for the level geometry. Thus, everything is solid without filling any polygons. This makes it really really fast :D I may also write a tutorial on how to do this type of rendering as it's a bit involved and I'd really like to teach other people all the techniques I've found or discovered myself.
So are the things solid? I'm confused by the third screenshot.
Yup things are solid, it's just easier to work in wireframe as I'm developing the clipping algorithm :D
So instead of polygon filling you just don't draw the lines that are covered up?
Exactly! To achieve this, I use a modified version of portal rendering. Pretty much, you have a 3D polygon that is your portal (such as a doorway). Through this portal you clip any lines against the portal. So longs as your rooms are convex, you can draw them in any order and it makes things solid! Suppose we have this level (the camera is blue and the portal is colored orange, also please forgive my mspaint skills and crappy 3D drawing skills :P):
[spoiler=Basic Portal Rendering](https://img.ourl.ca/portal1.png)
Suppose you were rendering this scene in wireframe from the perspective of the camera. What do you think you'd see? Something like this (the portal is still orange and the red lines are those outside of the portal):
(https://img.ourl.ca/portal2.png)
Now, just clip out the lines outside your portal polygon and viola, you have a solid rendering of both rooms!
(https://img.ourl.ca/portal3.png)
Obviously, the process is much more complex (especially when multiple rooms are visible, geometry is behind the camera, etc) but that's the general idea. The most expensive part of rendering is the clipping. But, with it in place we don't have to do any Z-sorting or polygon filling! :D[/spoiler]
But with this method you would theoretically have to split up some lines right? In your diagram you have that but what do you do to accomplish it?
That really looks impressive Catastropher. Thanks for sharing this project. I am curious about what kind of game could be done using this engine. :)
Also sorry about your health issues. I hope it's nothing too bad.
Quote from: CKH4 on June 27, 2015, 05:05:09 AM
But with this method you would theoretically have to split up some lines right? In your diagram you have that but what do you do to accomplish it?
Indeed you do. There are a few different algorithms to accomplish this. The canonical polygon clipping algorithm is Sutherland-Hodgman (https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm (https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm)). For a prism, you'd have to clip each polygon separately (a prism has n + 2 polygon, so for an octagonal prism you'd have to clip 10 polygons) and then draw the visible edges after clipping. Worse, it has a time complexity of O(n^2), and you're running it for each polygon. I'm working on a better algorithm for prism clipping, but I'm still working out all the details. I'll make a post when it's done :)
Quote from: DJ Omnimaga on June 27, 2015, 05:29:24 AM
That really looks impressive Catastropher. Thanks for sharing this project. I am curious about what kind of game could be done using this engine. :)
Thanks! I hope people will get interested in it and make some cool stuff! But I'm still developing the core, so it may be a bit before it's ready.
Quote from: DJ Omnimaga on June 27, 2015, 05:29:24 AM
Also sorry about your health issues. I hope it's nothing too bad.
Thanks for the concern, that's really nice of you :) It's nothing too bad, just some rheumatoid arthritis that flares up every once in a while (yup, I have it at 20 :()
Looks good, as before. Keep going :)
Whoa, awesome! So how good does this compete against glib for example?
Also i thought Portal used FrameBuffers and all that advanced stuff for portals :P
Quote from: Cumred_Snektron on June 27, 2015, 09:49:44 AM
Whoa, awesome! So how good does this compete against glib for example?
You should note that the screen is a 68K screen :P It hasn't been writed for z80 yet.
Also, I did try that few year ago on z80, it worked, (1 portal bring down the whole scene to about 9 fps) but the main issue that I encounter is that the cliping is a very expensive method to use on z80 (that is, no div or mul command), and should be evited. But it is still definitly doable.
I'm amazed at the speed and the quality of the screenshot you gave us. 3D untextured solid? Collisions? Cinematics? Mazette!
Next thing you know someone made Assassins Creed Unity for calculators :P
Quote from: Cumred_Snektron on June 28, 2015, 09:23:27 AM
Next thing you know someone made Assassins Creed Unity for calculators :P
Only the Nspire could do that :P
ACUnity? i'd prefer Team Fortress 2! :p
I'm sure most people would. It's less resource intensive but the downfall is that it's (pretty much (I think that there's an offline tutorial)) multi only.
Quote from: Duke "Tape" Eiyeron on June 28, 2015, 07:56:34 PM
ACUnity? i'd prefer Team Fortress 2! :p
The point was it was something that uses a lot of system resources :P
Why not just a spinoff rather than a game port? It could even be 2D and be based on Assassin's Creed and Team Fortress. Of course it could use X3D too. :)
Quote from: TheMachine02 on June 28, 2015, 09:50:55 AM
Quote from: Cumred_Snektron on June 28, 2015, 09:23:27 AM
Next thing you know someone made Assassins Creed Unity for calculators :P
Only the Nspire could do that :P
Challenge accepted 8)
Quote from: Duke "Tape" Eiyeron on June 27, 2015, 10:49:32 PM
I'm amazed at the speed and the quality of the screenshot you gave us. 3D untextured solid? Collisions? Cinematics? Mazette!
Thanks! :) Just wait, there is much more to come!
Quote from: Lionel Debroux on June 27, 2015, 06:34:15 AM
Looks good, as before. Keep going :)
Thank you! Also, thank you for writing the optimization tutorial! It will be a great help! :)
Quote from: CKH4 on June 28, 2015, 08:10:46 PM
I'm sure most people would. It's less resource intensive but the downfall is that it's (pretty much (I think that there's an offline tutorial)) multi only.
While I don't think X3D could handle anything that complex, it will certainly have multiplayer support. The idea is that both calcs have synced random number generators, so the only data that needs to be sent back and forth is which keys each player is pressing. That way, both calculators are actually running separate copies of the game and the data sent back and forth is minimized :)
Quote from: TheMachine02 on June 27, 2015, 10:25:19 AM
Quote from: Cumred_Snektron on June 27, 2015, 09:49:44 AM
Whoa, awesome! So how good does this compete against glib for example?
You should note that the screen is a 68K screen :P It hasn't been writed for z80 yet.
Also, I did try that few year ago on z80, it worked, (1 portal bring down the whole scene to about 9 fps) but the main issue that I encounter is that the cliping is a very expensive method to use on z80 (that is, no div or mul command), and should be evited. But it is still definitly doable.
Yeah Z80 support will be much harder to achieve, but X3D is very aggressive with culling things that aren't visible. First though I have to get the engine rewrite working for the 68k calcs!
Quote from: DJ Omnimaga on June 29, 2015, 07:45:33 AM
Why not just a spinoff rather than a game port? It could even be 2D and be based on Assassin's Creed and Team Fortress. Of course it could use X3D too. :)
My hope for X3D is that it could be used to both "port" other games and be used to create new games. I had posted this list of planned features on Omnimaga, but no one really took notice there so I'll post it here as well :)
- It's now a library so anyone can use it in their code!
- Cross platform (currently builds for TIGCC/GCC4TI and GCC)
- Levels constructed of convex interconnected prisms instead of cubes (so you could have e.g. an octagonal prism tunnel)
- Three different types of portals - these will allow a portal gun and so many other neat features (will discuss later)
- Vector graphics for textures i.e. line art (like the holo switch) drawn on walls
- Moving objects (like e.g. robots in Descent)
- Materials that can be attached to a face e.g. glass, which mean it's breakable
- Doors
- A simple scripting language?
- Moving platforms
- A simple physics engine for collision detection
- Weapons
As always, thank you everyone! You're all giving me a lot more motivation to work on it! :D
Ooh nice to see it's a lib. Also it's good that it supports both TIGCC and GCC4TI since TIGCC hasn't been updated since 2009.
As for Portal, assuming you mean like the game, I wonder if it will lag much when seeing through portals, especially 9 iterations of them?
Keep up the good work :)
Well, though I hope to one day support a system to make a game of Portal, "portal rendering" refers to a rendering technique to allow efficient clipping and determination of what geometry is visible. In the old version of X3D, levels were made of connected cubes that share a face. This shared face is a "portal" from one cube into the other (which is a like a portal in the game "Portal"). So, to answer your question, the old version of X3D ran at about 15-20 fps with 10 portals visible, as can be seen in this walk-through (though there were a few glitches):
[spoiler=X3D Walkthrough](https://img.ourl.ca/X3D%20V2.GIF)[/spoiler]
In the new version, I'm hoping to get this even faster :D
that looks awesome :O
Now I know what kind of game it made me think : Antichamber, because the whole "all white, outlines in black". Obviously it lacks color for the gun/cubes/props.
Yeah i thought of that too. it would be awesome if you could make Antichamber in it, thohgh it probably uses a lot of FBO's and Shaders
Wow, this is slick! I'll give it a whirl on my newly obtained TI-92+ when I find some free time. Also, glad to see that the rumours about the 68k scene dying out aren't quite true ;)
Quote from: utz on June 29, 2015, 08:00:38 PM
Wow, this is slick! I'll give it a whirl on my newly obtained TI-92+ when I find some free time. Also, glad to see that the rumours about the 68k scene dying out aren't quite true ;)
Hey thanks! The only thing is that that version of X3D was an old version from April. I probably could find a build of it if you wanted to give it a whirl though! :D I'm hoping to get something working for the rewrite soon though, so stay tuned!
This looks amazing O.O
Quote from: alexgt on July 03, 2015, 01:33:58 AM
This looks amazing O.O
Ya think?
Isn't the z80 series faster though? I'm suprissed that this can run on the 68k calcs O.O
Yes and no. The ti 89 titanium is the only one that's faster than the ti 84+ series but the rest are faster than the 83+ series.
Quote from: CKH4 on July 03, 2015, 02:45:41 AM
Yes and no. The ti 89 titanium is the only one that's faster than the ti 84+ series but the rest are faster than the 83+ series.
hmmm, interesting... Isn't the 83+ SE the same speed as the 84+ though?
For some reason I thought that the ti 83+ se only added mem. Apparently it's dual speed 6 and 15. I guess that's why I thought that it was only 6.
Even though some of the Z80 calcs have a faster clock speed, the 68k calcs have native multiplication and division instructions (though slow), 16 32-bit registers, and a number of other things that make a 12 MHz 68k outperform a 15MHz Z80 i.e. it's a just a more powerful processor.
Quote from: Unicorn on July 03, 2015, 02:41:12 AM
Quote from: alexgt on July 03, 2015, 01:33:58 AM
This looks amazing O.O
Ya think?
Isn't the z80 series faster though? I'm suprissed that this can run on the 68k calcs O.O
There is Nostromo that demonstrates how fast 3D can be on Z80 calcs, but I don't know if the maps are as complex as X3D. It seems to run at good speed, though: http://www.benryves.com/journal/tags/Nostromo/all
(http://www.benryves.com/images/nostromo/bsp/2010.11.28/Walkthrough.gif)
IIRC, this screenshot runs at 6 MHz (entirely possible considering who made that ASM program), but I could be wrong.
Also just because the TI-84+SE runs at 15 MHz and the TI-89/92+/v200 at 12 MHz doesn't mean it's necessarily faster. The Z80 is a 8 bits processor, while the 68K one is 32 bits.
Indeed, the TI-68k series has always been significantly more powerful than the TI-Z80 series, and the Nspire series significantly more powerful than the TI-68k series :)
The relative popularity of the TI-Z80 series and TI-68k series is a consequence of standardized testing acceptance at the first order, and price tag at the second order. And as we all know, lower performance does not mean that one can't do great things on a given platform by leveraging all of its power.
The recent TI-eZ80 series is closing the gap, with a 24-bit flat addressing space, 256 KB of RAM and 4 MB of Flash, just like the 89T, and a faster processor. However, the eZ80 remains a 8-bit CPU with few registers, and represents an older generation than the 68000. Both were designed in the 1970s, nearly 40 years ago by now. What's more, TI is shackling the eZ80 with all of those memory access wait states, effectively reducing the processor speed to a quarter or an eighth of the maximum speed - which weakens a lot the eZ80's ability to drive a 320x240 screen at an optimal filling rate.
For select USB transfers, e.g. sending screenshots or FlashApps to the computer, the TI-eZ80 series seems faster than the 89T, which could be explained pretty much only by the usage of a DMA.
Someone should really make some hack for the CE at some point, unleashing it's full potential.
Though its probably quite hard, since you possibly need to kill the asic
I'd be cautious about releasing it if you weren't completely sure that your methods couldn't be broken by ti. I'm sure that they'd rather release a broken OS upgrade that temporarily bricks some people's calcs then bother to properly patch the exploit.
Quote from: Cumred_Snektron on July 03, 2015, 03:51:18 PM
Someone should really make some hack for the CE at some point, unleashing it's full potential.
Though its probably quite hard, since you possibly need to kill the asic
And the Prime but it is powerful of and by itself.
I threw together a simple on-calc level editor because I needed a test level! The spinning line shows which face is currently selected. Note that the image is running much faster than the actual version.
[spoiler=X3D Level Editor]
(https://img.ourl.ca/EDITOR.GIF)
[/spoiler]
Edit: I should point out that this project is open source and anyone can contribute! Here' the link to the source code: https://github.com/catastropher/X3D-68k (https://github.com/catastropher/X3D-68k)
Awesome O.O I wish that the real speed was as fast as that but that looks amazing :)
And the proccesors have been explained :) Thanks guys.
Quote from: Lionel Debroux on July 03, 2015, 05:23:07 AM
Indeed, the TI-68k series has always been significantly more powerful than the TI-Z80 series, and the Nspire series significantly more powerful than the TI-68k series :)
The relative popularity of the TI-Z80 series and TI-68k series is a consequence of standardized testing acceptance at the first order, and price tag at the second order. And as we all know, lower performance does not mean that one can't do great things on a given platform by leveraging all of its power.
I will never understand TI's marketing tactics for the 68K series. Why do they insist on charging as much for a 16 MHz calc with 188 KB of RAM and 2.7 MB of flash as they do for a 150+ MHz calc with 64 MB of RAM and 100 MB Flash? It's almost like if they tried to make 68K calcs sell as less as possible to justify their eventual discontinuation. In Canada, the TI-84+CE and HP Prime calcs are now $150 (the latter was $200 last Fall), while the Nspire CX CAS is $165. One store even has the 89T for $15 more than the Nspire CX CAS right now, which is a disgrace. The 89T should be $155 at most.
Quote from: catastropher on July 06, 2015, 05:43:57 PM
I threw together a simple on-calc level editor because I needed a test level! The spinning line shows which face is currently selected. Note that the image is running much faster than the actual version.
[spoiler=X3D Level Editor]
(https://img.ourl.ca/EDITOR.GIF)
[/spoiler]
Edit: I should point out that this project is open source and anyone can contribute! Here' the link to the source code: https://github.com/catastropher/X3D-68k (https://github.com/catastropher/X3D-68k)
Woah, that is nice Catastropher! O.O I am curious if I might be able to do some levels easily in it. A FPS with custom maps would be great. :)
Quote from: DJ Omnimaga on July 09, 2015, 02:18:29 AM
I will never understand TI's marketing tactics for the 68K series. Why do they insist on charging as much for a 16 MHz calc with 188 KB of RAM and 2.7 MB of flash as they do for a 150+ MHz calc with 64 MB of RAM and 100 MB Flash? It's almost like if they tried to make 68K calcs sell as less as possible to justify their eventual discontinuation. In Canada, the TI-84+CE and HP Prime calcs are now $150 (the latter was $200 last Fall), while the Nspire CX CAS is $165. One store even has the 89T for $15 more than the Nspire CX CAS right now, which is a disgrace. The 89T should be $155 at most.
What's interesting is that I bought a practically brand new TI92+ for $35 a few months ago O.O Unfortunately, TI doesn't care too much about the 68k calcs anymore. Still, they're a pretty neat platform, hence why I'm making this. DJ, don't you have a regular TI92? I wonder if I could get X3D to work with that too.
Quote from: DJ Omnimaga on July 09, 2015, 02:18:29 AM
Woah, that is nice Catastropher! O.O I am curious if I might be able to do some levels easily in it. A FPS with custom maps would be great. :)
Thanks! :D My hope is to have both an on-calc editor and a PC editor. In addition, there will eventually be a simple scripting language! I just need to brush up on my 68k assembly skills to get everything fast enough :P One of my friends, Jason aka
@Kalbrandr has come onboard the project, so hopefully things will move a bit faster now!
I got a 92 but the link port is sluggish and I never figured out how to install Fargo. Instructions seemed pretty cryptic.
So today I got a very basic version of solid mode working. It's crappy, sluggish, and glitchy but it's a start :P The number at the top of the screen shows how many ticks it took to render the scene (1 tick = 1/350th of a second). Most of the time is spent in the polygon clipper, which will be replaced soon with a better algorithm I came up with. My apologies for the erratic screenshot!
[spoiler](https://img.omnimaga.org/EDITOR2.GIF)[/spoiler]
Things that really need to be worked on:
- The level editor controls are very difficult to use as is (you can see me struggling in the image :P)
- It's using the old clipping algorithm as I'm getting the new one working - this adds an O(n^2) algorithm to each face with a segment on the other side :(
- You currently can't move between rooms
- Some lines are unnecessarily being drawn twice, which is why some of them look extra thick
- For some reason the engine keeps freezing every once in a while, also noticeable in the image
Anyway, just thought I'd get something out here to show that progress is being made :)
Wow that level editor is impressive, you may want to add a toggle for the solid fill.
Thanks! The project has come a long way since I restarted it a few months ago :) I will indeed add a toggle, thanks for the suggestion! The funny thing is, the engine actually runs faster in solid mode because it can discard entire parts of the level if they're not visible. In wireframe mode, you unfortunately have no choice but to practically draw everything :(
That's an interesting upside to the solid mode. I'm really glad to see the progress. What calculators does this run on, I might try to find one that can run this because of how great it is.
Quote from: CKH4 on July 13, 2015, 10:26:49 PM
That's an interesting upside to the solid mode. I'm really glad to see the progress. What calculators does this run on, I might try to find one that can run this because of how great it is.
Aww thanks! Currently it only runs on the 68k calculators (TI92+, Voyage 200, and the TI89), but I'll eventually be providing ports for the NSpire and PC. Really, it can run on anything that GCC can target for and is powerful enough to run it :)
Btw, the source is code is here: https://github.com/catastropher/X3D-68k (https://github.com/catastropher/X3D-68k) (most development is currently being done in the segment branch). If you give me a few days to iron out some of the bugs, I'd be happy to upload some binaries (which can be run with TIEmu if you don't have a physical calc) :D
Oooh, sounds great. Does the ti 89 category contain titanium as well? (I'm not too familiar with 68k)
Also I'll take a look at the source. I might learn something.
Quote from: CKH4 on July 13, 2015, 10:45:17 PM
Oooh, sounds great. Does the ti 89 category contain titanium as well? (I'm not too familiar with 68k)
It does indeed! The only thing is, the TI89 family tends to be more expensive. Though the TI92+ was discontinued a long time ago, it has a 240x128 screen and you can buy them online pretty cheap (I got mine a few months ago for 35 USD). The TI89 on the other hand has twice as much flash and a 16 MHz CPU (compared to the 12 MHz TI92+) but it only has a 160x100 display. X3D runs on them both though! Actually, it will run faster on the TI89 because of the faster clock speed.
Quote from: CKH4 on July 13, 2015, 10:45:17 PM
Also I'll take a look at the source. I might learn something.
Sweet! Don't hesitate to ask me any questions you have (the source code is currenly just a bit messy since I've been quickly doing several things. Most of it is documented using Doxygen though!) Also, feel free to contribute if you'd like. It's completely open source so anyone can take part! :D
QuoteThe number at the top of the screen shows how many ticks it took to render the scene (1 tick = 1/350th of a second).
350 Hz sounds like you used AUTO_INT_1 for timing, which is a good idea on HW2+ calculators from 1999 onwards - but in such a case, the rate is 256 Hz :)
Only HW1 calculators "feature" that inaccurate and varying AUTO_INT_1 rate, usually said to be 350-395 Hz (depending on battery strength, the phase of the moon, etc.).
Quote(which can be run with TIEmu if you don't have a physical calc)
Or https://tiplanet.org/pad_ti68k_emu/v12.html , started by Patrick Davidson and largely improved by myself. It aims at being an install-less, portable, "good enough" emulator. It's unfinished - it lacks a debugger, to begin with - and it was started before Emscripten became a usable option, but it works for most purposes.
QuoteThe TI89 on the other hand has twice as much flash and a 16 MHz CPU (compared to the 12 MHz TI92+) but it only has a 160x100 display. X3D runs on them both though! Actually, it will run faster on the TI89 because of the faster clock speed.
The CPU frequency of the 89 and 92+ is the same, actually.
Now, the frequency of the 89T's CPU was at first thought to be ~16 MHz, but it was a benchmarking issue stemming from comparing an empty 89T to a loaded 89, which had consequences on the memory allocation and VAT subsystems. Pure assembly benchmarks didn't show such a significant speed difference.
From the dependencies on Github:
* you're linking to the obsolete and unmaintained TIGCC, but not to the newer, improved and less buggy GCC4TI - how sad ;)
* copying third-party headers / libraries to the GCC4TI environment can certainly cause issues with some projects and end up referencing files from the environment when one would like to reference other files, so I'm not keen on anyone copying ExtGraph (or any widely used third-party library, again) there.
Quote from: Lionel Debroux on July 14, 2015, 05:59:19 AM
350 Hz sounds like you used AUTO_INT_1 for timing, which is a good idea on HW2+ calculators from 1999 onwards - but in such a case, the rate is 256 Hz :)
Only HW1 calculators "feature" that inaccurate and varying AUTO_INT_1 rate, usually said to be 350-395 Hz (depending on battery strength, the phase of the moon, etc.).
Ah ok, thanks. The documentation on https://debrouxl.github.io/gcc4ti/intr.html#SetIntVec (https://debrouxl.github.io/gcc4ti/intr.html#SetIntVec) still says 350 with without mentioning this is only for HW1. Is there someway we could update this?
Quote from: Lionel Debroux on July 14, 2015, 05:59:19 AM
Or https://tiplanet.org/pad_ti68k_emu/v12.html , started by Patrick Davidson and largely improved by myself. It aims at being an install-less, portable, "good enough" emulator. It's unfinished - it lacks a debugger, to begin with - and it was started before Emscripten became a usable option, but it works for most purposes.
Oh, I didn't realize there were other emulators! I will have to give this a try :)
Quote from: Lionel Debroux on July 14, 2015, 05:59:19 AM
The CPU frequency of the 89 and 92+ is the same, actually.
Now, the frequency of the 89T's CPU was at first thought to be ~16 MHz, but it was a benchmarking issue stemming from comparing an empty 89T to a loaded 89, which had consequences on the memory allocation and VAT subsystems. Pure assembly benchmarks didn't show such a significant speed difference.
This is what I get for trusting the information from Wikipedia (incorrect box on the right still shows 16 MHz https://en.wikipedia.org/wiki/TI-89_series#TI-89_Titanium (https://en.wikipedia.org/wiki/TI-89_series#TI-89_Titanium)) :P
Quote from: Lionel Debroux on July 14, 2015, 05:59:19 AM
* you're linking to the obsolete and unmaintained TIGCC, but not to the newer, improved and less buggy GCC4TI - how sad ;)
Oops, sorry about that! I wrote that readme in a hurry and forgot to link to both. I'll get that corrected as soon as I can!
Quote from: Lionel Debroux on July 14, 2015, 05:59:19 AM
* copying third-party headers / libraries to the GCC4TI environment can certainly cause issues with some projects and end up referencing files from the environment when one would like to reference other files, so I'm not keen on anyone copying ExtGraph (or any widely used third-party library, again) there.
Oh alright, I wasn't aware of this problem. Should I just include the extgraph header in my repository in X3D-68k/src/headers?
Thanks for correcting me, I certainly don't want to be propagating misinformation (apologies if I already have)!
QuoteThe documentation on https://debrouxl.github.io/gcc4ti/intr.html#SetIntVec still says 350 with without mentioning this is only for HW1. Is there someway we could update this?
Just did it locally :)
Given that this is not the only piece of inaccurate/outdated information in the trunk/tigcc/doc/System/Include/intr.h/SetIntVec.hsf file (for instance, on HW3/4, AUTO_INT_3 no longer is a 1 Hz timer, it's used for USB), a more involved pass on this page and several of its siblings is warranted. It's just another proof that most of the GCC4TI documentation was written in the late 1990s and early 2000s, before the V200 (2002) and 89T (2004) became available for purchase. Documentation and library work largely stagnated after 2002-2003 for multiple reasons outside of the scope of this topic, such work only resumed with GCC4TI.
The authoritative resource for documentation on the TI-68k series' hardware (for HW1 and HW2, that is) is known as "J89hw.txt", mainly written by Johan Eilert, and improved later based on newer work by e.g. ExtendeD (port 70001F, for instance).
The most recent version of that file is in the TIEmu repository, and mirrored at http://tict.ticalc.org/docs/J89hw.txt . IOW, I'm supposed to be the maintainer of both the file and the mirror. ExtendeD's newest work on HW3/4 I/O ports (710000-7100FF) was never reformatted for inclusion into that file, and no emulator emulates most of those ports.
QuoteOh, I didn't realize there were other emulators!
This one is intentionally not widely advertised, because it's unfinished, and probably will stay that way, as performance and accuracy are already good (i.e. the "good enough" goal for pure consumers has already been largely achieved), and there are barely any TI-68k native code developers left - you're one of the few exceptions, precisely :)
Nowadays, the proper way to write a TI-68k emulator would be to rewrite a pure C/C++ code base, starting from the TIEmu code base, and use Emscripten to target asm.js and soon WebAssembly.
QuoteShould I just include the extgraph header in my repository in X3D-68k/src/headers?
You can copy or link the files from ExtGraph to that location on your computer, but please do not add them to the repository: there are already too many outdated versions of ExtGraph being shipped around :)
It's likely that even some TICT software, i.e. myself, is guilty.
Quote from: Lionel Debroux on July 14, 2015, 11:54:14 AM
Just did it locally :)
Given that this is not the only piece of inaccurate/outdated information in the trunk/tigcc/doc/System/Include/intr.h/SetIntVec.hsf file (for instance, on HW3/4, AUTO_INT_3 no longer is a 1 Hz timer, it's used for USB), a more involved pass on this page and several of its siblings is warranted. It's just another proof that most of the GCC4TI documentation was written in the late 1990s and early 2000s, before the V200 (2002) and 89T (2004) became available for purchase. Documentation and library work largely stagnated after 2002-2003 for multiple reasons outside of the scope of this topic, such work only resumed with GCC4TI.
Great thanks! Let me know if there's anything I can do to help! I want to do as much as I can to help breath life into the platform :)
Quote from: Lionel Debroux on July 14, 2015, 11:54:14 AM
The authoritative resource for documentation on the TI-68k series' hardware (for HW1 and HW2, that is) is known as "J89hw.txt", mainly written by Johan Eilert, and improved later based on newer work by e.g. ExtendeD (port 70001F, for instance).
The most recent version of that file is in the TIEmu repository, and mirrored at http://tict.ticalc.org/docs/J89hw.txt . IOW, I'm supposed to be the maintainer of both the file and the mirror. ExtendeD's newest work on HW3/4 I/O ports (710000-7100FF) was never reformatted for inclusion into that file, and no emulator emulates most of those ports.
Thanks for the resource! Sorry again for being misinformed :P
Quote from: Lionel Debroux on July 14, 2015, 11:54:14 AM
You can copy or link the files from ExtGraph to that location on your computer, but please do not add them to the repository: there are already too many outdated versions of ExtGraph being shipped around :)
It's likely that even some TICT software, i.e. myself, is guilty.
Awesome, I'll update the readme and includes when I get the chance :D
Edit: I updated the readme with a link to GCC4TI instead of TIGCC :) I will update the code to expect extgraph in a different folder soon, after which I will update the readme again.
IIRC, the last update in TIGCC was adding Windows Vista support in 2007 or 2009 O.O . I'M glad that someone took over to maintain it. I can't wait for X3D updates to see more of this program into action :)
By the way, are there 68K emulators that allows you to slow down emulation, like with Nspire_emu and WabbitEmu? That can be handy during screen capture with Camstudio and such software, because then you can speed the video back up and you get much smoother screenshots that do the program's justice and it would be nice for people without 68K calcs to see an animated screenshot showing the full speed potential of this engine. :)
Yes, the JS TI-68k emulator can slow emulation down. However, it does not support producing animated screenshots by itself, unlike jsTIfied.
Full Vista+ (UAC) support was actually added after TIGCC became unmaintained for practical purposes, as part of GCC4TI.
That's good. I normally use a third-party video capture software then I convert the AVI into GIF, and I produced particularly smooth (although sometimes very large) animated GIFs or AVI files of TI-Nspire programs before. Most old 68K screenshots flickers and/or lags a lot.
Hello guys! I would like to apologize for my extended absence. X3D is still being very actively developed though! However, we've had difficulty getting the project organized. Worse, X3D was originally developed as a static library, but we've found that the size is just too big. Thus, the project is now going be a DLL (for the core) and a static library (for extra features). So... the entire project is going to be written (for what, the 5th time now? :P) If anyone is interested in joining the project, now would be the perfect time because there's a lot to do and many opportunities to contribute! There's not much code currently, but check out https://github.com/catastropher/X3D-68k/wiki/Building-For-68k-Calculators (https://github.com/catastropher/X3D-68k/wiki/Building-For-68k-Calculators) for how to build it!
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.
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 :)
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.
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 ;)
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?
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.
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
(http://img.codewalr.us/x3dcemockup.png) (http://img.codewalr.us/x3dcemockup2.png)
TI-84+CSE
(http://img.codewalr.us/x3dcsemockup.png)
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.
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 :)
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:
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!
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 :)
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!
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)?
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 (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! :)
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)
Quote from: DJ Omnimaga on August 22, 2015, 01:39:47 AM
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.
That tends to happen to me lately :P
Quote from: Cumred_Snektron on August 22, 2015, 10:14:57 AM
Quote from: DJ Omnimaga on August 22, 2015, 01:39:47 AM
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.
That tends to happen to me lately :P
Can't even tell you how many times I've done this!
So today I worked on bouncing physics for objects. Since the camera is an object, what better way to test it?
[spoiler=X3D Bouncing Physics](https://img.omnimaga.org/BOUNCE3.GIF)[/spoiler]
The renderer is kind of glitching out here and bouncing currently has some difficulty when hitting an edge between two rooms, but it's a solid start! :D
Haha that's pretty cool actually. As for the glitching I assume you mean the diagonal lines appearing in the roof or one of the walls?
Yeah, I still have one or two (i.e. several) bugs to iron out haha Of course, the camera would probably never be moving like this; my thought was more for bouncy projectiles. Although, you could have a bouncy floor material ;)
By the way, when this engine becomes mostly functional, do you plan to create a mini game out of it? A puzzle platformer where you use the objects to reach other areas would rule as an example game, plus it could convince some people to use the engine for their own games (if we get more 68K coders, that is) :D
Portal 6(8k) :P
Yeah, everyone wants Portal in 3D for calcs I know. :P But I thought that a smaller scale project might be better to start up and to quickly showcase some of X3D capabilities
Half Life 3 (68k).
/me runs
Quote from: DJ Omnimaga on August 23, 2015, 12:30:39 AM
By the way, when this engine becomes mostly functional, do you plan to create a mini game out of it? A puzzle platformer where you use the objects to reach other areas would rule as an example game, plus it could convince some people to use the engine for their own games (if we get more 68K coders, that is) :D
Indeed I do! I just have no idea what I'd make yet :P First I should probably get the engine to a usable state. Ideally, a game that could run on one of the platforms should be runable on the others as well.
Quote from: CKH4 on August 23, 2015, 10:06:43 AM
Portal 6(8k) :P
This may actually be possible once the dynamic portal system is in place (or at least a scaled down version of Portal). The thing I'm worried about is seeing a portal through a portal. I may have to set a recursion limit to prevent this. Descent is another that I'd really like to get working.
Quote from: catastropher on August 23, 2015, 05:13:44 PM
The thing I'm worried about is seeing a portal through a portal. I may have to set a recursion limit to prevent this.
Welp. You even must do it :P Even "true" portal game as a recursion limit. Just iterate for a fixed number of time and discard everything when the limit is hit.
Either way, sound a promising project,that come along nicely :)
A true see though portal? that would be amazing O.O
Quote from: TheMachine02 on August 23, 2015, 07:49:26 PM
Quote from: catastropher on August 23, 2015, 05:13:44 PM
The thing I'm worried about is seeing a portal through a portal. I may have to set a recursion limit to prevent this.
Welp. You even must do it :P Even "true" portal game as a recursion limit. Just iterate for a fixed number of time and discard everything when the limit is hit.
Either way, sound a promising project,that come along nicely :)
Thanks! I :D Yeah, the previous version had a recursion limit, I just haven't gotten around to implementing it in this version yet... there's so much that needs to be done!
Quote from: Cumred_Snektron on August 23, 2015, 08:51:23 PM
A true see though portal? that would be amazing O.O
Technically, the engine already does this: there's an implicit portal everywhere that two rooms (called "segments") are connected. I'll just have to add special cases for portals on walls. Of course, free-standing portals are a bit more tricky, but are still doable. I hope to one day add a portal gun for shooting a portal onto a wall ;)
In case anyone is interested as to what I worked on today, I did more work on the object system and added a bouncing box! It's still really glitchy, but hey, it's something! :D
[spoiler=X3D Bouncing Box](https://img.omnimaga.org/BOUNCE4.GIF)[/spoiler]
I wonder what would be the performance of a see-through Portal game... it would definitively need a recursion limit (perhaps 3 maximum?) in case someone use a camera angle that almost freezes the game >.<. Or perhaps the game could stop rendering stuff as soon as it hits a certain time limit? (for example if you want 8 FPS then it would stop rendering lines as soon as it reaches 0.125 seconds of render time) But that could look weird at times.
Also Catastropher that is really cool :D. Will the engine support 2D scaled sprites? I forgot if it did or if it will do. It might allow more type of graphics in the game (such as a ball in this case)
Quote from: DJ Omnimaga on August 24, 2015, 01:41:46 PM
I wonder what would be the performance of a see-through Portal game... it would definitively need a recursion limit (perhaps 3 maximum?) in case someone use a camera angle that almost freezes the game >.<. Or perhaps the game could stop rendering stuff as soon as it hits a certain time limit? (for example if you want 8 FPS then it would stop rendering lines as soon as it reaches 0.125 seconds of render time) But that could look weird at times.
I'll have to play around with different solutions once I get the dynamic portal system working. Another thing I could do is to not allow you to place a portal in a spot where it's visible from the other one, though I'm not sure if I like that idea.
Quote from: DJ Omnimaga on August 24, 2015, 01:41:46 PM
Also Catastropher that is really cool :D. Will the engine support 2D scaled sprites? I forgot if it did or if it will do. It might allow more type of graphics in the game (such as a ball in this case)
Thanks! I made it so now you can have multiple boxes bouncing at the same time! :D As for 2D facing sprites, I've certainly considered it. The problem is that the sprites have to be clipped against doorways (i.e. the viewing frustum), and I don't know of an efficient method for doing this. In addition, with solid objects, you have no choice but to sort the objects by depth. This means doing a O(nlog n) sort every frame :( Worse, you have to draw white triangles to make them solid... With transparent objects, you don't have to do any sorting because it doesn't matter what order you draw them in. It'd suck if everything had to be transparent, but it really depends on whether I can come up with a really fast algorithm...
Yeah the idea might not be the best solution, else people will wonder why sometimes placing portals doesn't work.
And I see about 2D stuff. Sorry to hear
Quote from: DJ Omnimaga on August 24, 2015, 05:41:39 PM
Yeah the idea might not be the best solution, else people will wonder why sometimes placing portals doesn't work.
True... I may proved a few different options and let the client choose which to use.
Quote from: DJ Omnimaga on August 24, 2015, 05:41:39 PM
And I see about 2D stuff. Sorry to hear
Well hopefully I can come up with a solution. I just haven't put too much thought into it yet. Several times I'll think that something is infeasible until I come up with a clever way to do it ;)
Lol ok. But yeah don't worry too much about it if you can't implement 2D stuff. :)
Over the past few days I did more work on the physics engine. New features include:
- Gravity
- Friction
- Proper sliding along walls and ramps
- Proper collision resolution
- Two default modes of collision handling: bounce and slide
- Two types of bounding volumes for collision: sphere and capsule (for the player)
- Jumping
Here is a screenshot of it in action. Note: for some reason it's running at a faster speed than on the real calculator, so no, it's not bouncing thaaat quickly:
[spoiler=X3D Physics](https://img.omnimaga.org/PHYSICS.GIF)[/spoiler]
Looks cool. :D After how many bouncing blocks does the calculator starts slowing down considerably (by more than half the frame rate) by the way? I am curious about how slow it would get if you made a :walrii: with the outline made out of cubes bounce around far enough to be fully visible? :P
Hi guys, it's been forever since I've given an update, so here we go. I've been working on X3D almost constantly (if you check my github, you'll see I work on it almost everyday). I finally implemented my new clipping algorithm, which means it now draws a single room in 2/256 seconds (i.e. 128 FPS!). This is because the engine spent most of its time in the clipper, and I found a way to reduce the problem from O(n^4) to O(n^3). In theory, if we had 10 rooms to draw, the new algorithm will take 1/10 the time of the old one.
But then, a few weeks ago, I got talking with Jason. Because the algorithm is so much faster, we probably could get away with polygon filling i.e. filled walls (black or white). Then it occurred to us that honestly, grayscale wouldn't be that much more expensive. So, X3D will now render in grayscale.
[spoiler=X3D Grayscale](https://img.omnimaga.org/X3D%20gray.png)[/spoiler]
However, this image is being rendered with the old clipper. I have devised a clipping algorithm that clips and renders in a single pass (by clipping the scanlines). Because it's so simple and barely uses any division or multiplication, it may actually be nearly as fast to draw filled polygons as clipped lines O.O I'll be implementing it over the next few days and I'll keep you posted of my progress! Also, I'm happy to announce that Jason is back to working on the project with me! :)
Heya, nice to see you again, I hope things are going well :)
I am shocked at how good this looks like. It reminds me a bit of the Space Dementia II style, but I haven't gotten the chance to play that game since it didn't seem to work. I am curious about how smooth your engine will be on a real calculator. I wish 68K calcs had an emulator with slowdowns so we could take screenshots while emulation is slowed down then speed them up with a video/GIF editor.
Good job so far on this engine. Will it still be possible to use wireframe/lines with no filling? That might be better for certain color calculator models if you ported the engine.
Wow that looks amazing. I've always been fond of 3D stuff, as many know, so this really speaks to me :P
Holy ****, that looks amazing indeed! Congrats on the great progress.
Quote from: DJ Omnimaga on October 28, 2015, 05:00:57 PM
Heya, nice to see you again, I hope things are going well :)
Thanks! Things have been going pretty well, I've just been crazy busy with work and school! I'll try to post my progress more frequently though!
Quote from: DJ Omnimaga on October 28, 2015, 05:00:57 PM
I am shocked at how good this looks like. It reminds me a bit of the Space Dementia II style, but I haven't gotten the chance to play that game since it didn't seem to work. I am curious about how smooth your engine will be on a real calculator. I wish 68K calcs had an emulator with slowdowns so we could take screenshots while emulation is slowed down then speed them up with a video/GIF editor.
I too am curious how smooth it will be! haha This is actually the 4th clipping algorithm that I've tried. The first two were very very slow (used for the light bridge version). Then, over the summer, I created a new algorithm (which is hinted at in the first post of this thread). I finally got it implemented a few weeks ago... only to come up with a better algorithm a few days later that is several times better :P I'm currently implementing this now, actually, and will add some animated screenshots when its done! :)
Quote from: DJ Omnimaga on October 28, 2015, 05:00:57 PM
Good job so far on this engine. Will it still be possible to use wireframe/lines with no filling? That might be better for certain color calculator models if you ported the engine.
Thanks again! And yes, I plan to still allow outlined walls instead of filled :)
Quote from: matrefeytontias on October 28, 2015, 09:48:27 PM
Wow that looks amazing. I've always been fond of 3D stuff, as many know, so this really speaks to me :P
Hey thanks! I also am really fond of 3D stuff, especially when it means pushing the hardware of the calculator to its limits! There are many many more things in store though! I just need to get this clipping algorithm up and running first! :)
Quote from: utz on October 28, 2015, 11:38:54 PM
Holy ****, that looks amazing indeed! Congrats on the great progress.
Thank you as well! I have plans for lots more stuff, so hopefully I can keep impressing you guys!
That reminds me, would this engine be suitable for actual 3D models as well or is it mainly for maps?
Quote from: DJ Omnimaga on November 02, 2015, 07:19:53 AM
That reminds me, would this engine be suitable for actual 3D models as well or is it mainly for maps?
My goal is to support simple 3D models, in addition to facing sprites. Sorry for the delayed response!
As promised, here is a screenshot of grayscale in action! Note that the graphical glitches are due to the emulator not responding well to grayscale; these glitches are not present on the actual device. Currently you can't actually enter the room because it needs to do clipping against the near view-frustum plane. This will be in the works soon though!
[spoiler=Animated X3D Grayscale](https://img.omnimaga.org/GRAY2.GIF)[/spoiler]
That looks really nice, plus I like how the 3D environment can change in real time with animations and stuff. :)
Quote from: DJ Omnimaga on November 09, 2015, 05:46:09 PM
That looks really nice, plus I like how the 3D environment can change in real time with animations and stuff. :)
Thanks! I think going to grayscale was a good decision. The only tricky part will be getting it fast enough!
Can you get extra speed by reducing the resolution to 80x100 or 40x100, then scale it back up to 160x100 when time comes to display the result? From experience, details loss in 3D when lowering horizontal resolution are quite bearable, but it depends if your routine speed is dependent on screen size and if displaying something at 4 times its original resolution is slow or not.
Quote from: DJ Omnimaga on November 10, 2015, 06:52:21 AM
Can you get extra speed by reducing the resolution to 80x100 or 40x100, then scale it back up to 160x100 when time comes to display the result? From experience, details loss in 3D when lowering horizontal resolution are quite bearable, but it depends if your routine speed is dependent on screen size and if displaying something at 4 times its original resolution is slow or not.
Well one of the neat things about the monochrome calculators is that you can cram 8 pixels in a single byte. This means, if you're drawing a horizontal line/scanline you can set multiple pixels at once. Unfortunately, scaling is much more complicated because you're pretty much forced to read/set each pixel individually. Right now, the source of slowness comes about from my unoptimized polygon filler/clipper. However, I know some really good ways to improve it! :) I'd just like to say, many thanks to Lionel Debroux for extgraph and GCC4TI! X3D wouldn't be possible without them!
Ah I see. On the HP Prime, all you have to do is copy the graphic buffer of your choice then display it on the screen at any size you want. Slowdowns occur with scaled graphics, but can be worked around quite easily. Keep in mind that HP PPL language is closer in style to TI-BASIC, though, and that that calc runs at 400 MHz.
And yeah I was glad that Lionel released GCC4TI, because back then the only TIGCC updates were for Windows Vista support and nothing new was added since 2006 or so. GCC4TI fixed that.
Between TIGCC 0.96 Beta 8 in late October 2006, and the creation of GCC4TI, which was triggered in the summer of 2008 by thoroughly unrealistic development goals announced by the other Kevin, there were over 300 commits in TIGCC CVS, i.e. a bit more than a quarter of the TIGCC CVS history.
However, most of them were related to the KTIGCC (1 and 2) dead end. Among the dozens of commits to the toolchain and library between those dates, there are relatively minor features and bugfixes, but nothing of large impact, indeed.
Hi guys, sorry I've been gone for so long. I have, however, been working on X3D like crazy and am proud to announce four major changes to it since I last posted:
- It's actually a library now, instead of a stand-alone executable
- It can render in color (for color calculators/PC)
- The code was rewritten to be platform-independent to facilitate porting to other devices
- As of today, it can render wall portals, just like from the game Portal!!!
The last point is very very exciting, especially since I only go it to work today! It took me forever to figure out the matrix math haha Anyway, here is a demonstration of it running on PC (the red and green portals are connected):
[spoiler=X3D Portals]
(https://img.omnimaga.org/portal-3.gif)
[/spoiler]
There are still several bugs to fix, and there are currently a number of limitations (you can't yet put portals on the ceiling or floor and you can't walk through them). These will be implemented soon though! :D
Ohai nice to see you again Catastropher :3=
I like how X3D looks with the colored lines and black background. Portal support is definitively a nice feature :D. Would implementing portals on the floor slow the engine down?
Also for which platform is this screenshot from? I know the TI-84 Plus CE now supports C and has an emulator called CEmu. Keep up the good work :)
Ooooh, portals! Looks nice! How hard do you recon it'd be to port this to the Nspire? Or maybe even the GBA.
Looks pretty nice, indeed :)
Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 PM
Ohai nice to see you again Catastropher :3=
Yeah, it's great to be back! I actually just graduated a few weeks ago (now I'm off to grad school!)
Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 PM
I like how X3D looks with the colored lines and black background. Portal support is definitively a nice feature :D. Would implementing portals on the floor slow the engine down?
Thanks! And nope, it's the same speed to render, I just need to figure out the math of aligning the portal... in Portal, a portal casted on the ceiling or floor is rotated relative to the camera's rotation, so that's probably what I'll do.
Quote from: DJ Omnimaga on January 14, 2016, 05:48:51 PM
Also for which platform is this screenshot from? I know the TI-84 Plus CE now supports C and has an emulator called CEmu. Keep up the good work :)
This is from the PC, running at 320x240 (it can run at any resolution though). I wonder if the C compiler for the TI-84 Plus CE has the strange requirement of putting all variables at the beginning of functions (like SDCC). If so, I'm in for a lot of code reorganization :P
Quote from: Ivoah on January 14, 2016, 05:50:38 PM
Ooooh, portals! Looks nice! How hard do you recon it'd be to port this to the Nspire? Or maybe even the GBA.
Thanks! It should be fairly simple, actually. The code is organized into two pieces: the engine core, and the platform-dependent part. Every port of the engine has to implement a common interface (functions for e.g. clearing the screen, drawing the lines, reading which keys are pressed, etc). The renderer is very very fast (it can run on the 12 MHz 68k calculators) so it should be runnable on most platforms.
Quote from: Lionel Debroux on January 14, 2016, 07:13:48 PM
Looks pretty nice, indeed :)
Thanks! I really appreciate the encouragement! It's come a long way since I started last February! :D
Oh my god! PORTALS!
Quote from: SiphonicSugar on January 15, 2016, 12:40:38 AM
Oh my god! PORTALS!
Hehe yeah, my friend Jason and I are already talking about how we're going to implement a game of Portal with X3D :D The hope, of course, is that other people will become more interested in the engine as it progresses. Descent is also on the list of games to develop, but Portal will probably come first.
Yeah my main concern about portals is I did not know if the floor could be used like a wall. For example, I doubt Portal could be done with Doom or Wolfeinstein engine. :P
Also do you plan to implement a gradient background like the idea I suggested a while ago?
I'm glad you graduated, by the way. Congrats. :)
QuoteAs of today, it can render wall portals, just like from the game Portal!!!
Wow, that looks definitely impressive!
As I've done some 3D-related work in the past, I'd like to know how you did it.
The way I'd do it in a more "modern" 3D environment with textured polygons is the following:
1. Render view of player into FBO, use stencil buffer for the portal.
2. Keeping the stencil active, get the position of the player relative to the portal and apply it to the other one.
3. Using that as the camera, render the scene into the FBO. Objects between camera and portal have to be culled.
4. Blit FBO to screen.
Of course, while the single steps can be optimized, it's still a lot of work to do for a fairly slow CPU (not even GPU...),
So, how do you achive it in X3D with wireframe graphics? Especially, how are recursive portals rendered?
Quote from: Vogtinator on January 15, 2016, 09:49:17 PM
QuoteAs of today, it can render wall portals, just like from the game Portal!!!
Wow, that looks definitely impressive!
As I've done some 3D-related work in the past, I'd like to know how you did it.
The way I'd do it in a more "modern" 3D environment with textured polygons is the following:
1. Render view of player into FBO, use stencil buffer for the portal.
2. Keeping the stencil active, get the position of the player relative to the portal and apply it to the other one.
3. Using that as the camera, render the scene into the FBO. Objects between camera and portal have to be culled.
4. Blit FBO to screen.
Of course, while the single steps can be optimized, it's still a lot of work to do for a fairly slow CPU (not even GPU...),
So, how do you achive it in X3D with wireframe graphics? Especially, how are recursive portals rendered?
Hey! Thanks for taking interest in the engine! Well, rendering is a bit complicated to explain as it doesn't fill any polygons, nor does it do any Z sorting. Unfortunately, I had to create my own algorithms for this, so I'll do my best to explain (I wish there was a better resource to point you to). To understand how the portals work, I first need to explain how X3D does rendering. First off, the level is constructed of interconnected prisms that share a face. Between the shared face is an implicit portal connecting them. Second, all geometry in X3D is convex - including the rooms (called "segments") and the portals. This lets us make a number of assumptions:
- Walls in a segment can be drawn in any order
- Every wall in a segment is convex
- Every convex polygon can be split into two polylines, one on the left and one on the right. This means a 2D polygon can be represented as two arrays, holding the x_left and x_right coordinate of each scanline.
This is very important for clipping. Suppose we have a convex polygon that describes the region of the screen that is visible. If we represented the polygon as N lines, clipping a line L against the polygon would take 2N multiplications and N divisions. If we use the scanline approach though, we can do a binary search to clip the line (I can explain this more if you want), so each line takes O(log L) where L is the length of the line.
Of course, how do we get such a clipping region? When the renderer begins, the clipping region is set to the entire screen. When a portal is enountered (after being clipped against the near plane), a 2D clipping region is constructed for the portal. We don't necessarily want to keep the entire portal clipping region; we just want the part of it that's inside the parent clipping region. So, we need to calculate the intersection of the two, which can also be done with a binary search (intersection of two convex polygons is always a convex polygon).
Now, anything on the other side of the portal is clipped aginst this new clipping region. This already allows for "solid wireframe" - any lines that would break the illusion of being solid are clipped by the clipping region. Even better, the only "filled" polygons are the faces that have portals, and they are never actually filled.
I modified the engine to visualize the process that is happening for rendering. It proceedes as follows:
- The geometry of the current segment is fully drawn without clipping. Then, each line is clipped against the current clipping region, one by one.
- When a portal is encountered, the parent clipping region is shown (filled red), followed by a new clipping region for the portal (filled green).
- Then, they are intersected (filled blue) and the renderer draws the segment on the other side using this new clipping region. For a "remote portal", a camera transformation has to happen (I can explain it if you want, it's just some matrix and vector math). Luckily, this can be partially precomputed and only requires one matrix multiplication, two rotations, and two dotproducts to adjust it.
[spoiler=X3D Rendering](https://img.ourl.ca/render.gif)[/spoiler]
I hope this helps a little bit. It took me a long time to come up with algorithm, but there you go, solid 3D rendering for low-power devices :) Please, feel free to ask me any questions you have! Oh, and you can always look at the source code/contribute if you ever want to! The repository is here: https://github.com/catastropher/X3D-68k, though the code is a bit messy atm haha
I don't understand 3D but looking at this screenshot, I like visualizing how the 3D is rendered line by line :) . Also good move to make such screenshot after explaining, since some people are more visual and understand better with animations and pictures. :)
Quoteas it doesn't fill any polygons, nor does it do any Z sorting.
Does that mean that "freestanding" polygons aren't possible with X3D?
QuoteEvery convex polygon can be split into two polylines, one on the left and one on the right. This means a 2D polygon can be represented as two arrays, holding the x_left and x_right coordinate of each scanline.
Hm, doesn't that mean that you convert back and forth between a array of points and an array of scanlines?
QuoteFor a "remote portal", a camera transformation has to happen (I can explain it if you want, it's just some matrix and vector math). Luckily, this can be partially precomputed and only requires one matrix multiplication, two rotations, and two dotproducts to adjust it.
Why two rotations and dotproducts? As I see that you're basically copying the room the target portal is in behind the view portal, isn't one rotation and one translation enough,
so one matrix multiplication/rotation and one addition/translation?
QuotePlease, feel free to ask me any questions you have!
How are matrices implemented? Using proper 32-bit floats, 32-bit fixed-point or entirely different?
QuoteI hope this helps a little bit.
Yep, it does! Thanks :)
Quote from: catastropher on January 17, 2016, 12:29:56 AM
[spoiler=X3D Rendering](https://img.ourl.ca/render.gif)[/spoiler]
From your explanation, I think you always clip against a polygon defined as a set of vertices, right? While this probably is no problem at all for computers and more powerfull calculators, I wonder if filling that polygon on a seperate 'clipping' buffer and then drawing lines using a modified OR-logic could speed the engine up on z80 calculators, especially if you limit all portals to squares, since the calculations required for clipping tend to be quite slow on that platform.
Since drawing filled polygons is also quite slow on that platform, it may be a stupid idea though.
Quote from: ben_g on January 17, 2016, 01:06:11 PM
From your explanation, I think you always clip against a polygon defined as a set of vertices, right? While this probably is no problem at all for computers and more powerfull calculators, I wonder if filling that polygon on a seperate 'clipping' buffer and then drawing lines using a modified OR-logic could speed the engine up on z80 calculators, especially if you limit all portals to squares, since the calculations required for clipping tend to be quite slow on that platform.
Since drawing filled polygons is also quite slow on that platform, it may be a stupid idea though.
Actually, it is possible. Filling the portal onto a buffer, and use and logic to draw line is pretty much fast. It is only one poly/portal that need to be filled, altough a fast clear buffer is also need. It also take care of recursive portal with drawing the new portal taking into account the old portal with and logic too. I had played with this quite a bit, and this may the only possible solution to hace portal on z80. Standard clipping is just out of question, it is muchhhhhh too slow.
Btw, X3D is pretty much impressive. Keep up the good work !
Quote from: DJ Omnimaga on January 17, 2016, 08:11:10 AM
I don't understand 3D but looking at this screenshot, I like visualizing how the 3D is rendered line by line :) . Also good move to make such screenshot after explaining, since some people are more visual and understand better with animations and pictures. :)
Thanks! I tried explaining it with just text at first and it was impossible haha
Quote from: Vogtinator on January 17, 2016, 11:21:19 AM
Does that mean that "freestanding" polygons aren't possible with X3D?
No, they are possible using one of two methods. You can either clear the portal polygon before rendering or you can first use the portal as an "anti portal" and clip the lines already processed so that parts inside the portal are removed (this may generate an extra line). Depending on how many lines are being drawn and how big the portal polygon is, either may be faster. Neither is currently implemented, but they will be in the future :)
Quote from: Vogtinator on January 17, 2016, 11:21:19 AM
Hm, doesn't that mean that you convert back and forth between a array of points and an array of scanlines?
Yes, but only for the portal polygons. The conversion algorithm is very fast (it's the filling that is slow). The main reason for using this though, is that polygon-polygon intersections can be done really really fast. At first, I used sutherland-hodgman clipping algorithm, but for every portal in the scene that had a complexity of O(n^4). I came up with an algorithm in the summer that got it down to O(n^3). The new algorithm can do the intersection in O(n + log n) for each polygon, for a total of O(n^2) for the entire scene. Also, since it's convex we don't have to split it into triangles: we can generate one clipping region because of the polyline property.
Quote from: Vogtinator on January 17, 2016, 11:21:19 AM
Why two rotations and dotproducts? As I see that you're basically copying the room the target portal is in behind the view portal, isn't one rotation and one translation enough,
so one matrix multiplication/rotation and one addition/translation?
This one is ever harder to explain without a picture. I'll draw a picture a bit later to show why this is.
Quote from: Vogtinator on January 17, 2016, 11:21:19 AM
How are matrices implemented? Using proper 32-bit floats, 32-bit fixed-point or entirely different?
Matrices are 3x3 0.16 fixed-point numbers (1 is approximated as 0.9999). This is because the 68k only has native multiplication for two 16 bit numbers.
Quote from: Vogtinator on January 17, 2016, 11:21:19 AM
Yep, it does! Thanks :)
Glad I could help! :D
Quote from: ben_g on January 17, 2016, 01:06:11 PM
From your explanation, I think you always clip against a polygon defined as a set of vertices, right? While this probably is no problem at all for computers and more powerfull calculators, I wonder if filling that polygon on a seperate 'clipping' buffer and then drawing lines using a modified OR-logic could speed the engine up on z80 calculators, especially if you limit all portals to squares, since the calculations required for clipping tend to be quite slow on that platform.
The problem is, 3D projection can give you lines that are thousands of pixels long when they are close to the camera. So, no matter what you're going to have to clip the line to the screen. Normal clipping requires multiplication and possibly division for the clipping, whereas my clipping algorithm does a binary search by calculating the midpoint of the line (two additions and two right shifts by 1). This requires the x_left and x_right position for each scanline though. For such a small screen, this should be pretty fast to calculate. I have experience with Z80 assembly, so maybe one day I'll give it a try.
Quote from: TheMachine02 on January 17, 2016, 02:34:43 PM
Actually, it is possible. Filling the portal onto a buffer, and use and logic to draw line is pretty much fast. It is only one poly/portal that need to be filled, altough a fast clear buffer is also need. It also take care of recursive portal with drawing the new portal taking into account the old portal with and logic too. I had played with this quite a bit, and this may the only possible solution to hace portal on z80. Standard clipping is just out of question, it is muchhhhhh too slow.
Do you actually fill the portal polygon though? Using the method I described, you don't need to actually draw the portal.
Quote from: TheMachine02 on January 17, 2016, 02:34:43 PM
Btw, X3D is pretty much impressive. Keep up the good work !
Thanks! :D
By the way, I'm not sure if this is clear, but X3D never actually tries to draw lines that are invisible, nor does it ever fill in the portals. There were just part of the visualization :)
That's good I guess about not drawing lines that are invisible. I assume it would be a waste of CPU resources. :P
Quote from: catastropher on January 17, 2016, 03:54:28 PM
Do you actually fill the portal polygon though? Using the method I described, you don't need to actually draw the portal.
Yeah, there is filling. But of course the method you described with scanlin clip without drawing can works too. The only thing is that on z80, scanline conversion is what take the most of time. The pur fulling part may only be 50% of the whole triangle filling routine.
Quote from: catastropher on January 17, 2016, 03:54:28 PM
The problem is, 3D projection can give you lines that are thousands of pixels long when they are close to the camera. So, no matter what you're going to have to clip the line to the screen. Normal clipping requires multiplication and possibly division for the clipping, whereas my clipping algorithm does a binary search by calculating the midpoint of the line (two additions and two right shifts by 1). This requires the x_left and x_right position for each scanline though. For such a small screen, this should be pretty fast to calculate. I have experience with Z80 assembly, so maybe one day I'll give it a try.
However, 3D projection on z80 tend to overflow quite a bit. Do you handle overflow at all ? And yup, binary search is quite efficient in numerous case for 3D.
Quote from: TheMachine02 on January 18, 2016, 06:14:03 PM
However, 3D projection on z80 tend to overflow quite a bit. Do you handle overflow at all ? And yup, binary search is quite efficient in numerous case for 3D.
Currently not, clipping against the near plane and having points as 16-bit ints seems to not cause any trouble.
So, there have been numerous changes to X3D since I last posted, but one of the most visible changes is the ability to add fog (ignore the graphical glitches :P):
[spoiler=X3D Fog](https://img.ourl.ca/fog.gif)[/spoiler]
This will come in handy when we make Portal, as there tends to be a lot of deep chasms :)
Wait... how is that even possible? O.O Great job on that fog effect. Looks pretty smooth too. Does this allow you to not have to draw stuff far away and thus, increase speed? Also are you able to make the fog a different color than the rest of the screen or is that out of the question?
Also for which platform is that screenshot from?
Looks really nice! How are you calculating render distance/fog, if I may ask? I've been trying to work that out for a while on an old project of mine.
Nice, like the fog a lot. How did you do that btw
Quote from: DJ Omnimaga on January 26, 2016, 07:04:23 AM
Wait... how is that even possible? O.O Great job on that fog effect. Looks pretty smooth too. Does this allow you to not have to draw stuff far away and thus, increase speed? Also are you able to make the fog a different color than the rest of the screen or is that out of the question?
Also for which platform is that screenshot from?
My guess would be that he calculates the depth of the line and uses that as an opacity value. Having fog that has a different colour than the walls would only work when you either fill the walls or have a way to render the fog as a volume, both of which would be way more heavy.
How is the screenshot in color? Aren't all of the 68k calcs b/w?
Hey thanks for the encouragement everyone! Since a bunch of people asked, I'll just answer all at once. As
@ben_g speculated, I did something similar to alpha blending. The current implementation of "fog" only works for black though. It works as follows:
- Define a min_dist and max_dist. At min_dist, a color at full brightness and by max_dist, it is completely black
- Using linear interpolation, assign a color to each vertex by scaling the color based on its depth (the Z value after points have been translated/rotated to the camera)
- Call a modified line drawing routine that interpolates between the vertex colors as it draws the line
This gives the illusion of fog/darkness, though it isn't "true" fog. The idea is really that things become darker as their depth increases; thus, it really isn't suitable for other colors.
Now, on to other questions!
Quote from: DJ Omnimaga on January 26, 2016, 07:04:23 AM
Great job on that fog effect. Looks pretty smooth too. Does this allow you to not have to draw stuff far away and thus, increase speed?
Indeed! This is one of the few cool visual effects that actually decreases the amount of work done by the renderer haha
Quote from: DJ Omnimaga on January 26, 2016, 07:04:23 AM
Also for which platform is that screenshot from?
It's still running on PC, but I'm hopefully going to get the NSpire port up and running pretty soon. All of the algorithms have been designed to be really fast, all math is done without floating point, and obviously, most of what's drawn is lines :)
Quote from: Ivoah on January 27, 2016, 04:08:09 PM
How is the screenshot in color? Aren't all of the 68k calcs b/w?
Indeed, the name "X3D-68k" has become a bit of a misnomer as the library is now being designed to be cross-platform. I'll post some screenshots from other platforms as I get the engine ported :)
Oh, and surprise, X3D has its first solid object! :D
[spoiler=X3D Solid Object](https://img.ourl.ca/box.gif)[/spoiler]
This looks cool. Didn't it have solid moving cubes a while ago, though? Or were they just part of the map?
I would definitively like screenshots of the engine running on a TI-Nspire and TI-84 Plus CE. :) Also the CE supports multiple color depths apparently.
Quote from: DJ Omnimaga on January 28, 2016, 04:01:08 AM
This looks cool. Didn't it have solid moving cubes a while ago, though? Or were they just part of the map?
Thanks! Actually, the bouncing cubes in previous versions were wireframe. This is the first solid thing that can move :D
Ah, right. If you ever make a small game (eg a puzzle platformer) using this engine to showcase it, then there should be a puzzle with moving platforms and if you fall down you die in the pit :P
Quote from: DJ Omnimaga on January 28, 2016, 04:55:51 AM
Ah, right. If you ever make a small game (eg a puzzle platformer) using this engine to showcase it, then there should be a puzzle with moving platforms and if you fall down you die in the pit :P
Sounds like a good idea! I have several plans for games that will use the engine once it's done :)
I know I've been posting updates quite a bit, but it helps keep me motivated... so here's another update ;D
Latest changes include:
- The ability to actually walk between rooms
- Numerous bugfixes for the renderer
- Functionality to create more complex level geometry (e.g. the "pipe" in the ceiling of the screenshot)
- The ability to create wall line art that's attached to the wall (the 'X' in the screenshot is an example)
- Ability to have multiple solid objects in the same room (though this needs to be optimized)
Here's a (bug filled) demo. Note that the dimming of the lines in the pipe is due to a clipping bug:
[spoiler=X3D Update](https://img.ourl.ca/tunnel-1.gif)[/spoiler]
As always, thanks for the support guys! If you have any feature requests, let me know!
Gosh, this is really cool! O.O
Quote from: catastropher on January 28, 2016, 03:55:59 AM
Quote from: Ivoah on January 27, 2016, 04:08:09 PM
How is the screenshot in color? Aren't all of the 68k calcs b/w?
Indeed, the name "X3D-68k" has become a bit of a misnomer as the library is now being designed to be cross-platform. I'll post some screenshots from other platforms as I get the engine ported :)
Think you can port it to the Nspire CX?
Quote from: Ivoah on February 01, 2016, 09:20:06 PM
Think you can port it to the Nspire CX?
Certainly! :) I just want the engine to become a bit more stable (there are a lot of bugs) before I begin porting it. Strictly speaking, porting will not at all be difficult. I just need to upgrade the build system, implement a few platform-dependent functions for the nspire, and build it.
Of course, there are a million things that need to be done. My hope is that other people would like to contribute eventually and help it to become a community-driven project. This could mean working directly on the engine, helping to implement Portal or one of the other games, creating maps for the games, porting the engine to other platforms, testing, or any number of other things. As it turns out, this is a pretty big project ;)
I really hope you can finish it, if so I will use it all the time on my Nspire ;)
Quote from: alexgt on February 02, 2016, 02:35:56 AM
I really hope you can finish it, if so I will use it all the time on my Nspire ;)
Thanks! Well, that time may be closer than you think because I just ported X3D to the Nspire! :D Here's a screenshot (apologies for the low quality):
[spoiler=X3D on the Nspire](https://img.ourl.ca/x3d-nspire.jpg)[/spoiler]
I'll post a version for you guys to try as soon as a I can, but first, there are some major stability issues that need to be fixed...
Woah cool! I didn't this until today and am glad it works on the Nspire. How is the speed like?
Quote from: catastropher on February 09, 2016, 06:33:07 AM
Quote from: alexgt on February 02, 2016, 02:35:56 AM
I really hope you can finish it, if so I will use it all the time on my Nspire ;)
Thanks! Well, that time may be closer than you think because I just ported X3D to the Nspire! :D Here's a screenshot (apologies for the low quality):
[spoiler=X3D on the Nspire](https://img.ourl.ca/x3d-nspire.jpg)[/spoiler]
I'll post a version for you guys to try as soon as a I can, but first, there are some major stability issues that need to be fixed...
Looks great!
Quote from: DJ Omnimaga on February 11, 2016, 08:37:16 PM
Woah cool! I didn't this until today and am glad it works on the Nspire. How is the speed like?
It's really really fast. But don't take my word for it, give it a try (it's in the attachments)!
Quote from: Ivoah on February 11, 2016, 08:45:00 PM
Looks great!
Thanks!
So I've been experimenting with flat shading instead of just lines for the Nspire and here is the result:
[spoiler=Flat Shading](https://img.ourl.ca/filled.gif)[/spoiler]
It's going to be buggy, but let me know what you guys think! :D
Nspire keys:Looking: arrow keys
Forward/backward: 7/4
Quit: esc
Looks very cool. I'd make the light direction fixed instead of based on the camera though.
Quote from: ben_g on February 15, 2016, 07:12:39 PM
Looks very cool. I'd make the light direction fixed instead of based on the camera though.
Thanks! Yeah, it will be in the final version, I just wanted to show that the color of the faces wasn't static.
OMG, filled polygons? This is epic. I'll try this when I have a chance.
Also I need to make an icon so I can make a subforum for this project.
Quote from: DJ Omnimaga on February 15, 2016, 10:24:50 PM
OMG, filled polygons? This is epic. I'll try this when I have a chance.
Thanks! My teacher is letting me use this as my semester term project, so I'm doing quite a bit of work on it :)
Quote from: DJ Omnimaga on February 15, 2016, 10:24:50 PM
Also I need to make an icon so I can make a subforum for this project.
Thanks, that'd be great! :D
So, here are the most recent changes:
- Lighting has been changed to not be based on the camera orientation
- Portals have been updated to work in filled mode
- Portals can now be shot and placed in different rooms (but you have to be in that room to shoot it because I've been too lazy to implement proper raycasting that spans room boundaries)
- Portals can be placed on the ceiling, floor, and slanted surfaces
[spoiler=Color Portals!!!](https://img.ourl.ca/color-portal.gif)[/spoiler]
I would upload a demo, but there's one calculation that's done in floating point that's tricky to do in fixed point. I'll upload a demo once I figure it out.
I'm happy to see more and more schools or teachers allowing students to use calculator projects as their semester term projects and recognizing the value of calculator programming for future carreers. :)
Also the portal seems to work fairly well and I like how they have an outline :D
Yeah, I feel really lucky that I have such awesome professors :D Also thanks!
So... it was bound to happen eventually...
[spoiler=What We've All Been Waiting For](https://img.ourl.ca/walk-through-portal.gif)[/spoiler]
Oh, that's quite awesome! Good job :)
Thanks! It was really difficult to figure out all the math but it was totally worth it! You can walk through portals now! :w00t:
Now I wish I had an Nspire. Or my dream calc.
Quote from: Dudeman313 on February 19, 2016, 04:26:39 AM
Now I wish I had an Nspire. Or my dream calc.
It runs on PC too ;)
I don't know if I'd be able to use it. My laptop is now schoolwork only- nothing else. I migth still use it while every one's asleep, but until it also runs on Java, Symbian 9.2, or CE calculators, I can't try this out.
Quote from: Ivoah on February 19, 2016, 04:38:08 AM
I wonder if it could be ported to the GBA...
Well, if there's a version of gcc/llvm that targets it, then yes. I'd need to take a look at the specs though before I can say how well filled mode would work on it. The engine isn't too optimized yet because there's just so many other things a game engine needs (the project is currently 12.5k lines of C and it's taken me several months to write).
Quote from: Dudeman313 on February 19, 2016, 04:41:57 AM
I don't know if I'd be able to use it. My laptop is now schoolwork only- nothing else. I migth still use it while every one's asleep, but until it also runs on Java, Symbian 9.2, or CE calculators, I can't try this out.
CE calcs may one day be a possibility, but you could always try to make a port for Symbian. Assuming it has a version of SDL it wouldn't be too difficult. Why can you run Java programs but not native executables? Of course, you'd have to build it from source to run it on PC regardless.
A CE version would run between 3 to 4 times slower, but I wonder if by reducing the quality (eg no filled polygons or lower bitrate) it could run faster? Also
@Cumred_Snektron has been working on 3D stuff for the CE lately but only raymarching so far, not stuff that could be used in game. :P
The graphics peoduced are nice... The problem is it takes like 20 minutes to render. (Luckily i have 1666% speed mode ;D)
Fantastic work indeed :)
I've posted a followup in an old topic on TI-Planet, but clearly, the program deserves much better than that, when it's available :)
Quote from: Cumred_Snektron on February 19, 2016, 08:03:25 AM
The graphics peoduced are nice... The problem is it takes like 20 minutes to render. (Luckily i have 1666% speed mode ;D)
Yeah to be honest, this is why I think you should maybe concentrate your efforts on faster 3D stuff so that they can be useful to 84+CE programmers :P. Raymarching and raytracing are definitively not something that would be of practical use on a calculator, let alone a TI-84 Plus CE or TI-83 Premium CE. Raycasting, mode-7 (Mario Kart) and 3D polygons, on the other hand...
Quote from: DJ Omnimaga on February 19, 2016, 05:05:51 AM
A CE version would run between 3 to 4 times slower, but I wonder if by reducing the quality (eg no filled polygons or lower bitrate) it could run faster?
Well, just in case, I'm going to also support outline mode, which is how the engine rendered before. As even the 68k calcs can render that, it should be runnable on the CE calcs (I hope!)
Quote from: Lionel Debroux on February 19, 2016, 08:18:18 AM
Fantastic work indeed :)
I've posted a followup in an old topic on TI-Planet, but clearly, the program deserves much better than that, when it's available :)
Thank you so much! I remember you emailing me with encouragement last year, back before the engine was really capable of much. It really inspired me to keep going on the project :)
Yeah I agree. Small lines aren't all that slow on color calcs. THe main issue is erasing the screen or filling it, which can be slow on some models. I think it would be fine on the CE but only in low bitrate. Also there is now a sub-forum for this project :3=
Quote from: DJ Omnimaga on February 24, 2016, 03:53:33 AM
Also there is now a sub-forum for this project :3=
Thank you so much! I'm really excited! :D
Is (or will) this engine opensource?
For now, it's a school project, which is a valid reason for it to remain closed source (and have more and more diverse backup sources) - but indeed, when it's no longer a school project, catastropher would make a gift to the community by open-sourcing it :)
Alright, I was wrong, I didn't know about the repo or I forgot about it :)
Actually, it already is open source: https://github.com/catastropher/X3D-68k (I have permission from my teacher to do so) :) Just be warned, I've been implementing stuff like crazy and the code is badly in need of some refactoring. For now though, I think it's a better use of my time to finish implementing smooth shading and to begin working on the level editor :D
Quote from: catastropher on February 25, 2016, 04:04:02 PM
Actually, it already is open source: https://github.com/catastropher/X3D-68k (I have permission from my teacher to do so) :) Just be warned, I've been implementing stuff like crazy and the code is badly in need of some refactoring. For now though, I think it's a better use of my time to finish implementing smooth shading and to begin working on the level editor :D
I went to star your repo, and it turns out I already did :D
Quote from: Ivoah on February 25, 2016, 04:10:08 PM
I went to star your repo, and it turns out I already did :D
Haha that's right, I forgot you had! It's hard to believe that I've been working on this project for a year now (it's over 700 commits now and there were less than 100 before last summer). I've learned so much while working on the project, though I have so much more to learn. I can't wait until I have at least a partially working game. Then, who knows, other people may be interested in using the engine for their own projects! :D
You should cross post this to cemetech, I'm sure there are some people there who would be interested.
That would be cool indeed, especially if it's on Gitubu, since people could help. It of course depends of which direction you want to take this engine in, in which case it might be good to wait until you have the bulk of it done, or at least open-source it but add some guidelines in the readme or Github page to ensure for example that people don't turn your 3D portal engine into a 2D Pokémon clone or stuff like that. :P
EDIT Nvm for some reasons I landed one page earlier when clicking this topic and missed page 12 of new posts. I am surprised that the teacher allowed you to make it open-source, since it's a school project, but I guess he can always monitor the source code if he's worried that another student rips your code off.
Quote from: DJ Omnimaga on February 25, 2016, 06:08:37 PM
That would be cool indeed, especially if it's on Gitubu, since people could help. It of course depends of which direction you want to take this engine in, in which case it might be good to wait until you have the bulk of it done, or at least open-source it but add some guidelines in the readme or Github page to ensure for example that people don't turn your 3D portal engine into a 2D Pokémon clone or stuff like that. :P
Quote from: catastropher on February 25, 2016, 04:04:02 PM
Actually, it already is open source: https://github.com/catastropher/X3D-68k (I have permission from my teacher to do so) :) Just be warned, I've been implementing stuff like crazy and the code is badly in need of some refactoring. For now though, I think it's a better use of my time to finish implementing smooth shading and to begin working on the level editor :D
Yeah I saw I missed an entire page of post after I clicked reply. I landed on page 11 for some reasons >.< (I edited my post above to reflect that)
Quote from: DJ Omnimaga on February 25, 2016, 06:08:37 PM
I am surprised that the teacher allowed you to make it open-source, since it's a school project, but I guess he can always monitor the source code if he's worried that another student rips your code off.
So the class I'm in right now is called "Game Design" and most of the people in my class are learning to use Unity/Unreal to make a game. However, my teacher happens to be my thesis advisor (my thesis will be in graphics, surprise surprise :thumbsup:) and he's letting me use this project as a leaning experience
in lieu of all the class projects. So, here is a humorous list of why one of my classmates stealing my code is unlikely:
- I'm doing a custom project different from everyone else in the class
- The project is 12.5k lines of code and all the modules depend heavily on each other, so you'd literally have to copy all of the code to even get it to build
- X3D is written in C from scratch and everyone else has to do Unreal or Unity, which uses C++ and C# respectively - they'd never understand why invoking the C# compiler on my code wouldn't work
- It renders in 16-bit color with screen dithering, so they'd have a lot of explaining to do when my teacher asks why their Unity game looks like it's running on Windows 98
- They'd have to take responsibility for my terrible code and poor software engineering
- It'd take way too much effort to remove the GNU GPL header from every single file in the project
- No where is it documented that you have to set the X3D environment variable before building so uh.. good luck with the cryptic errors my CMake script will give (even I have been a victim of this)
- They'd never figure out the unintuitive key mappings I set up which removes the possibility of an in class demo, and they wouldn't know which #if 0's to reenable to even get something rendering
Haha ok humor aside, I want you all to imagine a world where there's a 3D engine that: runs on the TI-Nspire, renders with smooth Gouraud shading, has screen dithering to overcome the limited 16 bit color of said device, and has an in-progress level editor called XBuilder...
[spoiler=Whatever could this be](https://img.ourl.ca/xbuilder.jpeg)[/spoiler]
So the shading implementation isn't complete yet (it glitches really badly when geometry is clipped by the near plane) but I think we're off to a good start! :D
Aah I see now. Also it's nice that he let you use your own stuff. I hate school project requirements that restricts what you can do and what you can use or vice-versa. For example, we once had to make a treasure hunting game in VB6 that was like an RPG with no battle. But we had to include an highscore system, which totally doesn't fit in such game. I finally just didn't bother, knowing I would succeed anyway and was about to be accepted to college. I had 80/100 instead of 100/100 but whatever.
Also woah at that shading screenshot o.o. I wonder how fast it would run on a calculator...
If this is ported to the CE, I'd want to see it in a 3D version of Stacker. I saw a 3D Stacker game on either Android or iOS that I loved, but now I can't find it...
So... progress has been kind of slow because I'm actually creating a new algorithm (one that I may eventually publish!) There are several things that are in the works that I'm dying to release a demo of, but can't until I finish implementing them. But, in the meantime, I thought you may be interested in a little bit of eye candy of X3D's new rendering capability:
[spoiler](https://img.ourl.ca/cube.jpeg)[/spoiler]
Wait, it has textures now?? *.*
Darn, I wonder how fast it runs and how the speed would be with walls that use low resolution textures (eg Playstation 1 style). I bet textures must be very slow on the 84+CE, though. Will the engine still support texture-less mode?
Anyway awesome job, as always :)
Yeah,
@catastropher , that's just amazing.
Maybe if my mom lets me get another graphing calculator for High School, I'll get an Nspire. :D
Quote from: DJ Omnimaga on March 23, 2016, 04:44:45 AM
Wait, it has textures now?? *.*
Darn, I wonder how fast it runs and how the speed would be with walls that use low resolution textures (eg Playstation 1 style). I bet textures must be very slow on the 84+CE, though. Will the engine still support texture-less mode?
Anyway awesome job, as always :)
Well, if plain 3D is slow on the CE(
@Cumred_Snektron 's project), wouldn't textures be even slower?
Looks pretty good, as usual - keep up the good work :)
Quote from: Dudeman313 on March 23, 2016, 09:49:23 AM
...
Well, if plain 3D is slow on the CE( @Cumred_Snektron 's project), wouldn't textures be even slower?
Do you mean the raymarcher? Raymarching is a very heavy way to do 3D rendering, and it's even quite slow on computers. Standard polygon graphics with textures should be a lot faster.
Yes, I meant the raymarcher. I did not know that.
A raycaster with textures would be cool, though...
The TI-68k series has at least the FAT-Engine raycaster with textures, by TICT :)
I basically didn't touch that code base myself, unlike most other TICT code bases.
That looks pretty sweet! :o
Quote from: ben_g on March 23, 2016, 10:52:58 AM
Quote from: Dudeman313 on March 23, 2016, 09:49:23 AM
...
Well, if plain 3D is slow on the CE( @Cumred_Snektron 's project), wouldn't textures be even slower?
Do you mean the raymarcher? Raymarching is a very heavy way to do 3D rendering, and it's even quite slow on computers. Standard polygon graphics with textures should be a lot faster.
yes, but i too wonder how fast a 3D rasterizer works on a CE. I should try it some time...
Quote from: Lionel Debroux on March 23, 2016, 01:14:53 PM
The TI-68k series has at least the FAT-Engine raycaster with textures, by TICT :)
I basically didn't touch that code base myself, unlike most other TICT code bases.
That reminds me, Gemini 3D on the CE would rule. I bet it could run very fast even in full-screen. Maybe it could be remade to use X3D engine?
It worked ok on the CSE :)
(http://tr1p1ea.net/files/downloads/screenshots/geminic2.gif)
That is cool tr1p1ea. I really meant an actual graphical remake, though, as in, 320x240 resolution, perhaps in 4 bits mode, and full-screen with either updated or colored textures. :P That said, that is nice. I guess what helped Gemini is that it was originally a 6 MHz game, so even on the CSE it will run faster at that resolution. I definitively think that X3D will have speed issues on that calc, though, so perhaps focus would have to be on the CE.
Hi guys, sorry I've been away for so long (I am indeed still alive! haha) I have made much progress since I last posted. X3D has received numerous technical upgrades, including the ability to add textures to walls (and be properly clipped!)
For anyone who's interested in a bit of eye-candy (hopefully it'll look a bit familiar):
[spoiler](https://img.ourl.ca/textured.jpeg)[/spoiler]
Quote from: catastropher on April 19, 2016, 01:54:54 AM
Hi guys, sorry I've been away for so long (I am indeed still alive! haha) I have made much progress since I last posted. X3D has received numerous technical upgrades, including the ability to add textures to walls (and be properly clipped!)
For anyone who's interested in a bit of eye-candy (hopefully it'll look a bit familiar):
[spoiler](https://img.ourl.ca/textured.jpeg)[/spoiler]
Looking great! I love the cube :D
Quote from: Ivoah on April 19, 2016, 01:56:49 AM
Looking great! I love the cube :D
Thanks! I feel like I'm actually make some good progress... nPortal is really going to happen! :D
You managed 640x480 resolution on a TI-Nspire? O.O
Just kidding, this is looking better and better. Glad to see you still around :) (I was hoping things were going ok)
Quote from: DJ Omnimaga on April 19, 2016, 02:09:16 AM
You managed 640x480 resolution on a TI-Nspire? O.O
Haha well you see what I actually did is have the Nspire render the same scene 4 times with the camera in different positions. Then, I stitched them together to create the huge image! jk Though it does render on the Nspire (though not very fast because I haven't optimized it yet).
Quote from: DJ Omnimaga on April 19, 2016, 02:09:16 AM
Just kidding, this is looking better and better. Glad to see you still around :) (I was hoping things were going ok)
Thanks! People at my school still look at me like I'm crazy when I say I'm implementing Portal for the calculator... heck, I am a bit crazy aren't I? haha I actually took a break for like two weeks and then got really bored and went back to working on it :P
Lol, imagine if Nspire C had linking capabilities and someone made a game that had a quadruple screen mode that allowed one to use 4 TI-Nspires as one large screen. It would be akward XD
And yeah some people think that calculators can still only display graphs or that it's pointless to port a game to a $150 machine that is way inferior to smartphones. Well... here's the thing: It's an old-school machine (to a certain extent) and there are still people who program games for the $300 Commodore 64 :P (although people in Europe are lucky since PAL C64 are like $30). I still like pushing such machines or languages that they support to their limits. :) (and I'm 100% sure that April Fools joke on the front page would be feasible at half the speed the fake Wolfeinstein 3D screenshot runs at)
QuoteFor anyone who's interested in a bit of eye-candy (hopefully it'll look a bit familiar):
That looks great! Now add shadows and ambient occlusion to make it look even better :P
QuoteLol, imagine if Nspire C had linking capabilities
It has: https://hackspire.unsads.com/index.php/Syscalls#NavNet
Quoteand someone made a game that had a quadruple screen mode that allowed one to use 4 TI-Nspires as one large screen. It would be akward XD
*awesome!
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
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?
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.
Yeah I know, but maybe catastropher isn't willing to make an actual Mode 7 engine. :P
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!
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!
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.
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
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.
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?
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
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?
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
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. :)
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](http://i.imgur.com/OBMC99u.gif)[/spoiler]
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
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
Quote from: DJ Omnimaga on April 30, 2016, 04:43:38 PM
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
Thanks! :D Doors are awesome because they actually give a performance boost when they're closed (you don't have to draw what's on the other side). Yeah, secret doors would be really cool too!
I'm getting really excited about the progress I've been making. It's hard to believe that a few months ago this engine could only draw lines! Oh, and many thanks to my friend Jason and
@Ivoah who are now doing some work on the project as well!
Quote from: catastropher on April 30, 2016, 07:08:48 PM
I'm getting really excited about the progress I've been making. It's hard to believe that a few months ago this engine could only draw lines! Oh, and many thanks to my friend Jason and @Ivoah who are now doing some work on the project as well!
Heh, thanks. I haven't really had time to do much of anything, aside from update the build instructions in the README. Also, you should encourage your friend to make an account here!
Quote from: catastropher on April 30, 2016, 07:08:48 PM
Quote from: DJ Omnimaga on April 30, 2016, 04:43:38 PM
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
Thanks! :D Doors are awesome because they actually give a performance boost when they're closed (you don't have to draw what's on the other side). Yeah, secret doors would be really cool too!
I'm getting really excited about the progress I've been making. It's hard to believe that a few months ago this engine could only draw lines! Oh, and many thanks to my friend Jason and @Ivoah who are now doing some work on the project as well!
Nice. I was wondering actually if you drew stuff behind doors that were close. Also does the engine runs slower when you look close to a wall? I noticed this happens with certain 3D engines, although maybe it was mostly with raycasters. Bwang's raycaster for Ndless 1.0 did that.
Is Jason a CW member by the way?
Quote from: Ivoah on April 30, 2016, 11:34:46 PM
Heh, thanks. I haven't really had time to do much of anything, aside from update the build instructions in the README.
Well there's so much to do that everything helps! I know how busy things can get (the only reason I had time to work on this so much was because it replaced all my class projects over the semester for my game class).
Quote from: DJ Omnimaga on May 01, 2016, 05:06:24 AM
Nice. I was wondering actually if you drew stuff behind doors that were close. Also does the engine runs slower when you look close to a wall? I noticed this happens with certain 3D engines, although maybe it was mostly with raycasters. Bwang's raycaster for Ndless 1.0 did that.
Things actually get faster when you look really close at a wall because the engine can cull polygons that are totally invisible. Oh, I'm thinking about implementing some more types of doors eventually - ones that open fully to one side (like doom or wolf 3D) and ones that swing out. The latter will be the most difficult though because it has to move objects out of the way as it opens (or not open at all).
Quote from: DJ Omnimaga on May 01, 2016, 05:06:24 AM
Is Jason a CW member by the way?
He might be, I thought I nagged him to make an account a while ago. I'll ask him!
Aah ok, I was wondering since most forum users use different nicknames.
Yeah. Imagine if I was JKolade313 instead of Dudeman313... :blah:
So I was wondering if you had any luck working on this in the last 6 weeks? I am curious about how it looks like now. (assuming the project is still alive of course)
Wow, this is awesome.
Honestly, didn't know that the Nspire calculator was fast enough to handle 3d rendering like this.
Heya Viliami and welcome here :D. The Nspire CX is definitively very powerful.
Yea, I've been programming on my Casio fx-9860gii using the SDK and it is already starting to lag on my Color Switch game.
Ooh, nice to see another Casio programmer around.
@p4nix used to program for that calculator a lot, but he had issues getting the SDK to work on Linux so he quit, IIRC. I think advanced games are possible on that calc, though, beecause someone made a raycaster and
@tr1p1ea made a 3D engine run at 6 MHz fine on a TI-83+. It requires a lot of optimizing, though.
Hey guys, it's been a long time since I've posted anything. Things have been crazy busy because I started my internship and have been going to physical therapy for some tendon issues. I am still working on the project (I'm working really hard to improve the code quality) but there haven't been too many visible changes yet. There will be several cool things coming soon though! :D
Ooh, congrats on the Internship. Is your tendon issue due to the health issues you mentioned somewhere a while ago? That sucks either way, though.
I'm glad this is still progressing :)
@DJ Omnimaga I didn't quit, I use GCC now.
Nice 3d engine btw, I really like it :3
Oh ok, I thought you never could find any alternative to the official SDK. Linux and especially 64-bit Windows utilities for Casio fx-9860G development were pretty sparse in the past.
Back on topic,
@catastropher , does X3D still support shading?
I've been working more on the "line texture" abilities; now it's possible to add more complex line-art to walls. This will allows for fairly detailed scenes using art that is made entirely of lines. I may be in the minority here, but I actually like the look of sold wireframe rendering - it feels really retro to me for some reason!
[spoiler=Line-art](https://img.ourl.ca/lineart1.png)[/spoiler]
XBuilder has a simple line art editor now (though it kinda sucks because I implemented it all in one day). Making that aperture logo by hand with lines was really hard though XD
Wow I didn't know that kind of textures was possible. I assume you can assign them to each wall like with regular textures? I think this could be handy for writings and other effects.
Also can you mix both wireframe and textured mode? Someone could make a Celshading-like game like Zelda: Windwaker.
Quote from: catastropher on July 17, 2016, 03:22:16 PM
I've been working more on the "line texture" abilities; now it's possible to add more complex line-art to walls. This will allows for fairly detailed scenes using art that is made entirely of lines. I may be in the minority here, but I actually like the look of sold wireframe rendering - it feels really retro to me for some reason!
[spoiler=Line-art](https://img.ourl.ca/lineart1.png)[/spoiler]
XBuilder has a simple line art editor now (though it kinda sucks because I implemented it all in one day). Making that aperture logo by hand with lines was really hard though XD
Now you need to add the ability to render SVGs :P
Quote from: DJ Omnimaga on July 17, 2016, 03:40:28 PM
Wow I didn't know that kind of textures was possible. I assume you can assign them to each wall like with regular textures? I think this could be handy for writings and other effects.
That is indeed how they work! You'll also be able to attach them to the faces of models (which is what I plan to do for the companion cube and other things).
Quote from: DJ Omnimaga on July 17, 2016, 03:40:28 PM
Also can you mix both wireframe and textured mode? Someone could make a Celshading-like game like Zelda: Windwaker.
Hmmm... that's an interesting question. For right now, I'm just focusing on wireframe mode but I'll keep this in the back of my mind.
Quote from: Ivoah on July 17, 2016, 04:50:11 PM
Now you need to add the ability to render SVGs :P
Tbh, that's what they practically are, just with lines XD The great thing is that the "line textures" can be rotated and scaled without looking crappy! :D
Btw, I'm going to need beta testers at some point (phase 1 is almost done). Any takers?
Which platforms do you plan on targeting for the first beta ? :)
I have returned! Mwhahaha! I have been working on something new for X3D. It runs very very slow at the moment, but it will be much faster after some optimization. May I present: light maps!
[spoiler=X3D Light Map](https://img.ourl.ca/shadow.png)[/spoiler]
I only implemented this today so it still has a long way to go (implementing shadow mapping was hard but fun!). Light maps, which were used in Quake, allow for semi-realistic lighting by precomputing "light textures" for every polygon in the level. These are then applied on top of regular textures to create a lit, textured mapped environment. The only caveat is that they can only be used to for static lights and static objects. Still, I think the results will be very impressive! This currently runs at 1 fps on the calculator for a number of reasons (one of the reasons is that I'm using floats for the rasterizer instead of fixed point). I'm very guilty of too much optimization too soon so I will optimize once I get everything working.
Looks great! What would be required to allow dynamic light sources?
Glad to see you again Catastropher. That lightning effect looks cool! If you can manage to make it run at good speed I am starting to wonder if this engine will not end up having better shading and lightning than PS2/Dreamcast games? O.O
Very great work
@catastropher, as a person who only got displaying and moving away from a triangle (on one axis, lol) done yet I'm really jealous of your work :P
Keep it up and good luck optimizing your code.
Quote from: Ivoah on September 21, 2016, 01:47:40 AM
Looks great! What would be required to allow dynamic light sources?
Thanks! Probably an insane amount of computation power haha I'm going to do some research into how Quake did things. I'll let you know if I find a way to do it!
Quote from: DJ Omnimaga on September 21, 2016, 06:17:13 AM
Glad to see you again Catastropher. That lightning effect looks cool! If you can manage to make it run at good speed I am starting to wonder if this engine will not end up having better shading and lightning than PS2/Dreamcast games? O.O
Thanks, it's good to be back! Also, thank you! I'm hoping to really push the calc to its limits! :D
Quote from: p4nix on September 21, 2016, 05:09:43 PM
Very great work @catastropher, as a person who only got displaying and moving away from a triangle (on one axis, lol) done yet I'm really jealous of your work :P
Keep it up and good luck optimizing your code.
Thank you as well! If you ever need any help with anything, let me know!
Just be sure that the programmer can enable/disable engine features by just changing certain config values so that if they want their games to run on lower-end models (the TI-84 Plus CE, for example, if it ever gets supported), then they can run at decent speed at the cost of not having shading or lightning, for example.
Quote from: DJ Omnimaga on September 22, 2016, 02:01:28 AM
the TI-84 Plus CE, for example, if it ever gets supported
/me prepares for benchmarking :P
Anyway, more serioulsy, the light map is just awesome. Btw, how do you do your blending ? Your lightmap hold an intesnity or directy a light color ?
EDIT : if you want dynamic light I recommand to read this tutorial : http://learnopengl.com/#!Advanced-Lighting/Shadows/Shadow-Mapping which explain how to do shadow mapping, ie the actual technique.
Quote from: DJ Omnimaga on September 22, 2016, 02:01:28 AM
Just be sure that the programmer can enable/disable engine features by just changing certain config values so that if they want their games to run on lower-end models (the TI-84 Plus CE, for example, if it ever gets supported), then they can run at decent speed at the cost of not having shading or lightning, for example.
Yeah, I made sure to implement the engine so that it has a number of different rendering modes (currently it has line, flat shading, gouraud shading, texture, texture + gouraud shading, and texture + lightmap).
Quote from: TheMachine02 on September 22, 2016, 09:59:11 AM
Quote from: DJ Omnimaga on September 22, 2016, 02:01:28 AM
the TI-84 Plus CE, for example, if it ever gets supported
/me prepares for benchmarking :P
Anyway, more serioulsy, the light map is just awesome. Btw, how do you do your blending ? Your lightmap hold an intesnity or directy a light color ?
Thanks! Right now the lightmap holds the intensity, but I'm going to be changing the engine to use 256 color mode. This means I can use the following approach:
- The lightmaps are calculated using a very expensive preprocessing step in low-resolution, storing intensity
- When a polygon is visible, a high-resolution lightmap is built from the low-res one by using bilinear filtering
- The polygon's texture is combined with the lightmap to create the final texture that is displayed (this can be done using a color table)
- This final texture map can be cached and reused between frames. If it hasn't been used for a few frames it can be freed.
This sounds expensive, but will actually be very fast. I think I'm going to use Quake's color palette (https://quakewiki.org/wiki/Quake_palette). Although, I may allow the user to customize it.
In the last screenshot, I only had lightmap generator working. Here is the lightmap combined with texture mapping (using a very slow two texture method - this will be replaced with the above algorithm once I change the engine to use 256 color mode):
[spoiler=X3D Lightmap + Texture](https://img.ourl.ca/shadow2.png)[/spoiler]
I will post more of my progress when I make it!
I wonder how good this engine would look like with textures from Pokéwalrus? :P
Looks very good, as always, by the way. :)
Quote from: DJ Omnimaga on September 23, 2016, 03:39:04 AM
I wonder how good this engine would look like with textures from Pokéwalrus? :P
Feel free to send any textures my way!
Quote from: DJ Omnimaga on September 23, 2016, 03:39:04 AM
Looks very good, as always, by the way. :)
Thanks! :D
So I heavily optimized lightmap rendering. Things actually look pretty smooth now! Want to give it a try? Check out the attached demo program!
Keys:
- Look around: arrow keys
- Move forward/backward: 7/4
- Add a new light at the camera's current position and angle: enter
- Quit: esc
A few notes:
- You can add a light but you can't remove one (they become "baked" into the level)
- Adding a light might take a few seconds - computing light takes a lot of calculations (in floating point)! Also the screen will be flat shaded with weird colors as it's calculating. This is for debug purposes
- Only spotlights with a fixed angle are implemented currently - this will change in the future
- Don't walk outside the level because there's no collision detection! haha
- I use affine texture mapping so the textures may shift strangely at certain angles
- X3D now renders in 256 color mode (I stole Quake's color palette haha)
Please give me any feedback you may have! :D
Ooh a download! I'll have to try it out when I have time. Still need to try Reuben 3 >.<
Also here's a texture set (the brown stuff is walls and the green stuff with diagonal lines is the top of cliffs):
(http://img.codewalr.us/poketilescliffs.png)
Hey DJ, check this out:
[spoiler=Thing DJ should check out](https://img.ourl.ca/walrii-1.png)[/spoiler]
That is nice. :D there should be an easter egg with a TV with Walrii in it
O.O i am dying but sadly i don't have any supported calculators. :(
I hope
@catastropher still plans to post some updates to the forums in the future. I noticed this project is still being updated regularly, but now he only posts updates on Github :(
Hey guys! Sorry for the long hiatus, I had to take a break from the project for about two months for school/work. But, I have a number of exciting things in the works:
- XBuilder, X3D's level editor is in the works! You can already do basic level editing (I rewrote the entire thing yesterday)
- You can load models in the .obj file format (I loaded in the Utah Teapot!) but right now you can only render them in wireframe. Solid will come soon
- Matrices are being upgraded to be 4x4 instead of 3x3. This means you'll be able to make things like joints and robotic arms
- A better lightmap compiler that uses raytcasting instead of shadow mapping to get more accurate lights
- Major code refactoring for cleaner code :D
- A new combined lightmap/texture renderer that does perspective-correct texture mapping every 16 pixels
- Several other improvements lol
XBuilder is my main focus for the moment because it's hard to test things without a real level. Too bad I suck at level design :'( Oh, and one of my classmates has expressed interest in joining the project so I may not be totally alone in working on it anymore!
Quote from: DJ Omnimaga on December 21, 2016, 07:22:36 AM
I hope @catastropher still plans to post some updates to the forums in the future. I noticed this project is still being updated regularly, but now he only posts updates on Github :(
Sorry!!! I got really busy with life for a while; also I worry that sometimes I post too much and people get sick of hearing about it haha
Quote from: ztortat on December 20, 2016, 10:39:40 PM
O.O i am dying but sadly i don't have any supported calculators. :(
Hi! X3D runs on PC as well if you still want to try it (though things are in the process of being upgraded so the test project doesn't do too much at the moment)! As always, if anyone want to join the team, I can always use help with X3D, XBuilder, or soon to be XPortal :D At some point, I'll need to find people good at making Portal levels, though that's still a bit of a ways off haha
Aaah I see. You shouldn't worry about if you are posting too much updates or not on the forums. People generally like updates :). Of course it can take a while before people get time to reply so sometimes you might have to post twice in a row but for project updates it's fine. I'm glad at least that this project is still alive :)
XBuilder seems interesting. I wonder how easy it will be to use? Because I always had issues understanding how 3D level editors worked. Just with F-Zero X it takes me 3 hours to get a semi decent custom track to work >.<
By the way, what are the current compatible platforms?
Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
Aaah I see. You shouldn't worry about if you are posting too much updates or not on the forums. People generally like updates :). Of course it can take a while before people get time to reply so sometimes you might have to post twice in a row but for project updates it's fine. I'm glad at least that this project is still alive :)
Awesome! I'll be sure to post my progress more often again :)
Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
XBuilder seems interesting. I wonder how easy it will be to use? Because I always had issues understanding how 3D level editors worked. Just with F-Zero X it takes me 3 hours to get a semi decent custom track to work >.<
My goal is to make XBuilder really easy to use. Here's a screenie of me making a quick level:
[spoiler=XBuilder](https://img.ourl.ca/xbuilder.gif)[/spoiler]
As I've mentioned previously, levels in X3D are constructed of convex prisms (called "segments"). You can't see the mouse, but when a face's outline changes color, that means I clicked it. Blue is the primary selected face and white is the secondary - you can add a segment connecting the two selected faces. In this case, I added some octagonal prisms and used the extrude, connect, and shrink face tools to make the level. Oh, fun fact, XBuilder uses X3D for rendering haha
Quote from: DJ Omnimaga on December 22, 2016, 08:49:33 AM
By the way, what are the current compatible platforms?
Currently builds only work for Nspire and PC, but I will add more ports later on. At this point, the engine has diverged so much from its original form that it'd be nearly impossible to get to build for the 68k's anymore.
I just finished implementing X3D's .pak loader, which loads archive files (in the format used by Quake). This means levels can finally have multiple files packed into one nice archive. Now, instead of having to have dozens of files for a level you can just have one :D Now that that is complete, I'm going to implement adding textures to walls in XBuilder. Lamely, until this point, all the textures you've seen have been hard-coded on the walls and you couldn't add more textures.
Wow I actually like the idea. Hopefully this and being available on multiple platforms motivate some people to make their own games or levels out of this engine :)
i'm trying to find a download but i cant find it is it just me or there is none?
???
Quote from: ztortat on January 01, 2017, 03:17:56 PM
i'm trying to find a download but i cant find it is it just me or there is none?
???
Right now there aren't any official builds (you'd have to build it from source, which is available on my github here: https://github.com/catastropher (https://github.com/catastropher)). Currently though, the engine is a bit of a mess because I'm upgrading several components now that I'm getting a real level editor somewhat working (https://codewalr.us/index.php?topic=1802.0 (https://codewalr.us/index.php?topic=1802.0)). I'd suggest waiting a little while as I get this mess untangled haha
I assume that the older downloads attached to previous posts are still available, right? Of course, they're outdated, though, but he could definitively give those a try :)
Hey guys! I'm back by (un?)popular demand! Very big things have been happing with X3D. First off, X3D has been going through a major rewrite. Why? Because I'm working on loading Quake level files! As much as I liked XBuilder, I was never going to get anywhere with it. This way, we can use the Quake toolchain for creating maps. Also, I'm implementing a number of Quake technologies to speed up level rendering (such as binary space partitioning and potential visibility sets). This is incredibly exciting because the engine is actually making progress. This screenshot may not look like much, but this is actually the first level of Quake loaded into X3D:
[spoiler=First Level of Quake](https://img.ourl.ca/Screenshot_20170702_150015.png)[/spoiler]
The thing is, I really really need beta testers. Also, it would be a huuuuuge motivation if people were trying out the stuff I was writing as I worked on it. If you're interested, please let me know! It would be a huge help!
So you need beta testers, right? I would love to test! I have a monochrome Nspire, if that is helpful information for you.
I have a TI-Nspire CX and i would love to try it !
How fast is it ?
Quote from: 123outerme on July 02, 2017, 07:33:00 PM
So you need beta testers, right? I would love to test! I have a monochrome Nspire, if that is helpful information for you.
Quote from: gameblabla on July 03, 2017, 01:45:54 AM
I have a TI-Nspire CX and i would love to try it !
How fast is it ?
Awesome!!! Thank you guys! At the moment, it's still just PC because it's much easier to develop on (though I will soon produce builds for the calcs as well). Do either of you run Linux by any chance? My goal is to have a new testable release every 1-2 weeks to get things moving along.
Quote from: catastropher on July 03, 2017, 11:15:15 PM
Do either of you run Linux by any chance? My goal is to have a new testable release every 1-2 weeks to get things moving along.
I'm currently using Devuan linux (a Debian fork) and i can compile stuff.
Should i compile myself or should i try out your binaries?
Quote from: gameblabla on July 04, 2017, 12:03:16 AM
I'm currently using Devuan linux (a Debian fork) and i can compile stuff.
Should i compile myself or should i try out your binaries?
Awesome! Truth be told I don't have any binaries, so if you could compile it yourself that'd be great XD It's not quite ready for the first test though, I'll need a few more days to finish the current the sprint. I'll let you know when I'm ready! Thanks! :)
Hey guys! I have many exciting updates to announce:
- I implemented code for Quake's potential visibility set, so only BSP nodes that are potentially visible are sent down the rendering pipeline. Since Quake levels have thousands of polygons, this means huge speedups
- I got support for the Nspire up and running
- I added a custom implementation of Sorted Spans so that the level can be drawn with 0 overdraw and without Z-Buffering
- I implemented flat shading
- I added a memory manager to prevent memory leaks
Here's an animated screenshot:
[spoiler=X3D Quake E1M1](https://media.giphy.com/media/3oKIPBPaZmupMZLUHu/giphy.gif)[/spoiler]
Here's what the level looks like in Quake for comparison:
[spoiler=Regular Quake E1M1](https://i.ytimg.com/vi/UnoYBB9PRYE/maxresdefault.jpg)[/spoiler]
Also, I have a question that I hope someone may know the answer to. Ndless provides lcd_init(), which I use to put the calculator in 8-bit palette mode. If I do this, I get nearly double the framerate compared to using nSDL's palette mode (looking at the source, I saw that it just uses a color table to convert to 16-bit color). However, Ndless doesn't seem to provided any way to change the calculator's palette colors. Anyone know if this is possible? I need to change the color palette to reflect Quake's palette.
Looks impressive!
Now just textures, shadows, anti-aliasing and shaders are missing :P
Out of curiosity, did you try it on hardware as well? I noticed that there are some unexpected bottlenecks there, especially memory speed (simple blit is already much slower).
QuoteHowever, Ndless doesn't seem to provided any way to change the calculator's palette colors. Anyone know if this is possible?
Not with the public API, in fact ndless does not even know that SCR_320x240_8 is paletted. I didn't even want to add it, but did so as some programs that needed to be ported to HW-W used it, I had no choice...
I could add a new
bool lcd_set_prop(enum type, union value)
syscall for some more flexibility though and extend the definition of SCR_320x240_8 to mean 8 bit with palette. This would of course require a yet unreleased version of ndless_resources.
What do you think?
For now you could hack around by writing to REAL_SCREEN_BASE_ADDRESS and specifying "--uses-lcd-blit=false --240x320-support=true" to genzehn.
Quote from: Vogtinator on July 11, 2017, 06:17:22 PM
Looks impressive!
Now just textures, shadows, anti-aliasing and shaders are missing :P
Thanks! :) At least half of those are on the way! Guess which ones? :P
Quote from: Vogtinator on July 11, 2017, 06:17:22 PM
Out of curiosity, did you try it on hardware as well? I noticed that there are some unexpected bottlenecks there, especially memory speed (simple blit is already much slower).
I did indeed try it on the actual hardware using different screen update methods. Though first, I noticed in the nSDL repo that nsp_palette is a global variable:
static Uint16 nsp_palette[256] = {0};
I also noticed that the code to convert the screen to 16 bit color looks like this:
/* 8 bpp SW, 16 bpp HW */
NSP_DRAW_LOOP(
for ( j = 0, k = 0; k < row_bytes; j += 2, ++k )
*(Uint16 *)(dst_addr + j) = nsp_palette[src_addr[k]];
);
I noticed that every iteration of the loop is reading from nsp_palette, which is a global variable. Is the compiler smart enough to put the address of nsp_palette into a register? Otherwise, it may keep loading the absolute address of nsp_palette each time (or at least each row). If this is the case, it may help to put the address into a local variable.
I did some testing of different methods for displaying an 8-bit buffer to the screen. The first two assume the calculator is in 16-bit color mode, the last one assumes 8-bit color. To do so, I disabled all rendering in my engine (except for showing the frame rate). Here's version 1, which is similar to the code in nSDL:
unsigned int sdlColors[256]; // Color palette
unsigned char* pixel = screen->pixels;
unsigned char* pixelEnd = screen->pixels + 320 * 240;
unsigned short* pixelDest = REAL_SCREEN_BASE_ADDRESS;
do
{
*pixelDest++ = sdlColors[*pixel++];
} while(pixel < pixelEnd);
Using this method, I got 27 FPS (without rendering anything, just updating the screen). However, by changing the code to pack two 16-bit pixels into an int, I got 41 fps:
unsigned int sdlColors[256]; // Color palette
unsigned char* pixel = screen->pixels;
unsigned char* pixelEnd = screen->pixels + 320 * 240;
unsigned int* pixelDest = REAL_SCREEN_BASE_ADDRESS;
do
{
*pixelDest++ = (sdlColors[pixel[0]]) + (sdlColors[pixel[1]] << 16);
pixel += 2;
} while(pixel < pixelEnd);
Even better, if I set the calculator to be in 8-bit mode and just use a direct memcpy, I get 66 FPS:
memcpy(REAL_SCREEN_BASE_ADDRESS, screen->pixels, 320 * 240);
The only problem using this method is that I can't change the palette colors and it probably wouldn't work for 240*320 screen. Speaking of which, I may need to setup X3D to render sideways for those calcs XD Internally, I store all of my textures as 8-bit pixels because 1. that's what Quake did and 2. I can fit twice as many pixels into cache (which is a pathetic 4KB). As for current rendering speed, the average scene renders at ~15 FPS using method 2, and 25 FPS using method 3. Of course, I haven't put that much effort into optimizing it yet.
Quote from: Vogtinator on July 11, 2017, 06:17:22 PM
I could add a new bool lcd_set_prop(enum type, union value)
syscall for some more flexibility though and extend the definition of SCR_320x240_8 to mean 8 bit with palette. This would of course require a yet unreleased version of ndless_resources.
What do you think?
That would be awesome! Would it also be possible to provide a way to change the palette colors in hardware? Also, would it be possible to read the palette colors so we can restore them when the program exits?
Thank you so much! :3
Try this:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0293c/Chdehhhf.html
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0293c/I914328.html
Quote from: Legimet on July 12, 2017, 10:55:11 PM
Try this:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0293c/Chdehhhf.html
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0293c/I914328.html
Awesome, thank you!!! :D Do you know how I can get the base address of the LCD?
The palette registers are at at 0xC0000200 (0xC0000000 is the base address). These pages on Hackspire are a good reference: https://hackspire.org/index.php/Memory-mapped_I/O_ports.
You have to write one (32-bit) word at a time, and the structure is as given in the page I linked:
Bit | | Name | | Description |
[31] | | I | | Unused |
[30:26] | | R[4:0] | | Red palette data |
[25:21] | | G[4:0] | | Green palette data |
[20:16] | | B[4:0] | | Blue palette data |
[15] | | I | | Unused |
[14:10] | | R[4:0] | | Red palette data |
[9:5] | | G[4:0] | | Green palette data |
[4:0] | | B[4:0] | | Blue palette data |
For classic Nspires I believe only [25:22] and [4:1] are used but you should make sure.
Oh, and I forgot to say: you should do the usual
lcd_init(SCR_TYPE_INVALID);
before exiting to restore the mode and free any memory that was allocated (like on classic).
@Legimet Thank you very much! I'll implement this as soon as I get the chance! :)
Definitly awesome. :) How will you handle lightning with custom palette ?
Quote from: TheMachine02 on July 15, 2017, 02:30:00 PM
Definitly awesome. :)
Thank you very much! I think your 3D stuff is really awesome too! :3
Quote from: TheMachine02 on July 15, 2017, 02:30:00 PM
How will you handle lightning with custom palette ?
So for X3D I'm using Quake's color palette, which looks like this:
[spoiler=Quake Color Palette](https://quakewiki.org/w/images/0/09/Qpalette.png)[/spoiler]
This is used to build a 256x64 (I'll probably make it smaller for cache reasons) table that for a given palette color and light intensity, it will tell you the palette color that it maps to. The table when visualized looks like this:
[spoiler=Quake Light Colormap](https://quakewiki.org/w/images/7/72/Colormap.png)[/spoiler]
Looking up into a large table like that is expensive, especially for every texel, which is why textures and lightmaps are combined and cached into what are called surfaces. Michael Abrash, one of the devs for Quake described it really well in his book, Graphics Programming Black Book (http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919) Check out chapter 68, "Quake's Lighting Model". Also, checkout chapter 66 and chapter 67 to see how Quake drew the world geometry without any overdraw. I've modified their algorithm to be very cache friendly (still a WIP though).
I got perspective-corrective texture mapping working! It currently runs at 5 fps on the calc, but I have several optimizations planned:
- Instead of doing the perspective correction (which requires a division) every pixel, I'll do it every 16 or 32 pixels and use linear interpolation
- I'll use mip-mapping so that we won't get so many cache misses with textures that are far away
- I'll make it so the active edge table will share edges between adjacent polygons so we only have to scan half as many edges
Of course, I'll probably write an assembly version of the span renderer eventually. Here's what the results look like so far:
[spoiler=Textured First Quake Level](https://media.giphy.com/media/xUOrwhRTX4V7cH4bao/giphy.gif)[/spoiler]
On to optimizing! :3
Erm, catastropher ~~~ !
I compiled your program again but... it forces shutdown my computer !
That, without even needing root access !
If you want to try it in a vm, here :
https://gameblabla.nl/files/make_linux_crash.zip (https://gameblabla.nl/files/make_linux_crash.zip)
It f***ed up my keyboard too :(
By the way, there's no need to define your own __nspire__ macro. nspire-gcc already defines _TINSPIRE.
If anyone would like to give it a try, I have X3D rendering the first level of Quake on the Nspire CX between 10 and 20 fps :D To get it working on the calculator, download the zip here (https://drive.google.com/file/d/0B73I-oR04jr7U2JRaDFaTHNNcnc/view?usp=sharing), extract it, and send all of the files to your calculator. Depending on your version of Ndless, either run xtest.tns (newer versions) or xtest.prg.tns (older versions). When you start xtest, it will say "no level loaded". To fix this:
- Open the dev console by pressing 9
- Run the command "map e1m1"
- Wait a couple of seconds because it's a multi-megabyte file
- Enjoy!
Keys:
- Forward/backward: 7/4
- Look around: arrow keys
- Quit: Esc
- Open/close dev console: 9
- Autocomplete in the console: tab (hitting twice lists options)
Notes:
- If you're outside the level, it will render in red wireframe. It will switch to textured mode automatically when inside the level.
- If it crashes, the engine produces engine.log, so please send this to me as well as any steps I can take to reproduce the crash. Thanks!
- Don't run any of the other console commands other than map (they're experimental)
- Current leaf tells you where you are in the BSP tree and visible leaves tells you how many leaves are potentially visible from where you are
- The textures wobble a bit as you move - currently working on this
Please let me know how testing goes and thanks for giving it a try! Also,
@Legimet thanks, I'll fix this when I get the chance!
X3D now has lighting! Here's a screenshot:
[spoiler=X3D Static Lighting](https://media.giphy.com/media/xT39Dda4odKIsFaGeQ/giphy.gif)[/spoiler]
If you'd like to give it a try, here's the download link (https://tiplanet.org/forum/archives_voir.php?id=1120356)!
That looks so cool o/ keep it up !
Hey guys! As always I know it's been forever, but I've been constantly working on X3D since I last posted and the engine has come a long way! Here are a few of the things I've worked on since my last post:
- Hand-optimized the low level span renderer in assembly
- Wrote a physics engine (still a WIP)
- Added basic support for loading/rendering 3D models
- Implemented dynamic lighting (currently very slow on the calc and buggy)
- Figured out how to use TrenchBroom, a Quake level editor, and was able to create a custom test map
Here's an animated screenshot (be warned, the file size is quite large):
[spoiler=X3D Custom Map/Physics](https://media.giphy.com/media/xUOxf5mr6tCbsZYGWs/giphy.gif)[/spoiler]
On my calculator, which to be fair is overclocked, this level gets 15-22 fps when standing out in the open, which is where the most polygons are. The engine is really coming along. I've grown so much as a programmer while working on this project - hard to believe it's been almost 3 years now since I started (I began in Februrary 2015).
If anyone is interested, I'll put a demo exe up here along with the test map :3
Very cool catastropher. :thumbsup:
Are you still supporting the 68K calcs? ???
Quote from: Ranman on November 22, 2017, 06:47:54 AM
Very cool catastropher. :thumbsup:
Thank you! :3 I'm just getting started!
Quote from: Ranman on November 22, 2017, 06:47:54 AM
Are you still supporting the 68K calcs? ???
Unfortunately not, I switched the engine to be compatible with Quake levels and there's no way the 68k calcs could render one of the levels, even in wireframe. I probably should change the project description to reflect this xD
Well I've been on a coding binge for the last few weeks so I thought I'd give an update:
- Implemented mouselook (yaaay no more turning with arrow keys!)
- Implemented loading/rendering of level models
- Added object type system for game objects
- Added some builtin game objects, such as button and rising platform
- Added event system with triggers e.g. push a button makes a platform raise
- Figured out how to get paint on walls, which will be used for Portal gels!
- Added numerous upgrades to the physics engine
Here's a demo of a small Portal-like chamber with all of the aforementioned feature (aside from the paint):
[spoiler=Test Chamber](https://media.giphy.com/media/3o7525SJFZAlzNnONy/giphy.gif)[/spoiler]
I did my best to make it somewhat look like a Portal chamber. I'm very excited because the engine is finally getting to a point where you can start doing real things with it. If anyone is interested in giving the demo a try the source is on github! :D
Been working on the new portal rendering system :3
[spoiler=Screenshots]
(https://i.imgur.com/n5ngBHj.png)
(https://i.imgur.com/L9Lq5iF.png)
(https://i.imgur.com/itcL3k1.png)[/spoiler]
I've decided to switch to a 3 month release schedule so that I don't keep disappearing for 6 months at a time :P So I'm looking at releasing a playable demo in September. I'll make a post shortly with what my development goals are by then! I've been making a lot of structural changes to the engine since it's now written in C++ rather than C. This left 35k lines of code to be refactored... so I'm trying to balance adding new features with cleaning up what's there.
You are crazy dude, this is awesome.
I haven't been here to see the whole thread,
but is this all from scratch?
What libraries did you use?
This fascinates me to no end.
Quote from: mazhat on July 10, 2018, 04:22:02 AM
You are crazy dude, this is awesome.
Thank you very much! And I am indeed crazy haha
Quote from: mazhat on July 10, 2018, 04:22:02 AM
I haven't been here to see the whole thread,
but is this all from scratch?
What libraries did you use?
This fascinates me to no end.
Yup, this is entirely from scratch. Since the calculator has no GPU it's all software rendered. The source code is on my github, but it's in kind of an awkward state since I'm doing lots of refactoring.
This is awesome! I've been following along loosely on your Github, but I like how you've added Portal mechanics! Very interesting. Will you be using it to make a Portal game for the Nspire?