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.

Been working on the new portal rendering system :3

[spoiler=Screenshots]




[/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 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.

Thank you very much!

Well, I finally complete my masters today! I'm looking forward to getting back into the community and having time to work on projects again!

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][/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!

Quote from: Ranman on November 22, 2017, 06:47:54 AM
Very cool catastropher. 

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

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][/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

X3D now has lighting! Here's a screenshot:

[spoiler=X3D Static Lighting][/spoiler]

If you'd like to give it a try, here's the download link!

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 To get it working on the calculator, download the zip here, 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!

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][/spoiler]

On to optimizing! :3

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][/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][/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).

@Legimet Thank you very much! I'll implement this as soon as I get the chance!

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!!! Do you know how I can get the base address of the LCD?

Quote from: Vogtinator on July 11, 2017, 06:17:22 PM
Looks impressive!

Now just textures, shadows, anti-aliasing and shaders are missing

Thanks! At least half of those are on the way! Guess which ones? 

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

Code Select Expand

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

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][/spoiler]

Here's what the level looks like in Quake for comparison:

[spoiler=Regular Quake E1M1][/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.