Looks impressive!

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

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.

x64 is IA-64, I highly doubt that anyone of you has an Itanium system anywhere
The term got popular when Microsoft used it incorrectly for AMD64 and Intel-64 compatible editons of Windows, but it's still wrong.

QuoteI need to remove Symbols from it. It could be in any unorthodox way possible, but it needs to be done. Later I need to replace said functions with equivalent ones from .o files.

That is not possible if the ELF file is a EXECUTABLE and was not linked with --emit-relocs as it's impossible to reconstruct where the symbols are used.
You need to find and fixup all references yourself, IDA can tell you where most references are and even has a patch function (although manually assembly is required). This won't work that easily if relative branches were used, that may require using a constant placed in the literal pool.

Edit: You can also just append your modded functions to the ELF file and patch the main function to branch to the modified ones.

QuoteI should try without those lines, i hope GCC works properly on OpenSUSE !

As I'm using it on several Pis without issues, definitely.

QuoteAlso @Vogtinator, i tried OpenSUSE on my Pi and it gives me a black screen after the EFI messages.
It is giving me signal on my display but it is all black.

After which efi messages? If it's after GRUB2, you could try appending "rd.driver.blacklist=vc4" to the kernel cmdline and try booting with efifb.
Red and blue are swapped to a disagreement between u-boot and the kernel, but that's a minor issue...

Quote from: Juju on January 02, 2017, 07:59:48 AM
Eh, looks simple enough.

EDIT: Aaaah, look what I found. The newer versions were under different branches the whole time. 4.4 is still the default branch, but you can find 4.5 and up if you know where to look.

They don't work. Most drivers just break with porting so every version newer than 4.4 is broken in a different way.

Quotei know that. Unfortunely, their crappy branch is broken and is actually missing code !
I was unable to compile their downstream kernel (4.9 and 4.10 don't compile)

The downstream kernel is only version 4.4 currently.

QuoteUpstream 4.9 kernel does compile but the image file isn't recognized by my pi,
it gives me the rainbow screen of death.

The upstream kernel needs an upstream device tree supplied, did you add that?

QuoteI do wonder if i can't just use the kernel from OpenSUSE...

The openSUSE kernel is a bit special, it needs an UEFI environment to boot.
However, you can use u-boot from openSUSE standalone, which can be very helpful for debugging.

The instructions linked are only for the downstream kernel.

QuoteSince "X11" images is too big, i'm just downloading openSUSE-Leap42.2-ARM-JeOS-raspberrypi3.aarch64-2016.11.25-Build1.12.raw.xz,
is that okay ?
I don't know if JeOS image files are tested...

Yes, that should work as well, it just does not have X installed by default.

QuoteWell i just checked the kernel in Devuan and it seems to use an upstream 4.6 kernel. So i don't think the default kernel has VC4 available.

Depends on the backports, maybe they picked the rpi3 related patches up.

QuoteMaybe it's due to the insufficient power supply, (only 1A is not enough)
as the Leap images for example says that gfxterm was missing then it goes back to the grub menu. over and over again

You'll see insufficient power issues as the power LED flickers during undervoltage.

Did you try this image: http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliances/openSUSE-Leap42.2-ARM-X11-raspberrypi3.aarch64-2016.11.25-Build1.18.raw.xz
There are a lot of links floating around to outdated build artifacts (they need to be cleaned up...)

QuoteThere's modesetting available in Devuan but how to load it anyway ?
Do i have to just make sure i'm using the rpi linux kernel from next branch, an up-to-date Mesa and modprobe vc4?

On openSUSE/SLES it's called xf86-video-modesetting. No idea how it's called elsewhere.
Make sure that you're *not* using the raspbian/downstream kernel but rather a very recent (at least 4.9) upstream kernel instead
or an older version with backported patches.
Mesa needs to have the vc4 driver explicitly enabled.

QuoteFirst, i tried the Tumbleweed and Leap OpenSUSE images and they don't work... they just won't boot.
OpenSUSE said the images were experimental so they probably do not work.

openSUSE Leap 42.2 images use the same code as SLES, so you probably did something wrong there.
The Tumbleweed image uses the upstream kernel without any patches, so in theory it should work,
but in practive too much stuff is missing or broken.

QuoteBut like @Streetwalrus said, i was going to be disappointed because it simply doesn't have VC4 or the proprietary drivers, only framebuffer support.
I have no idea how to compile VC4's driver for X11 so needless to say, i started to look at other options.

There seems to be some confusion here. VC4 is just the name of the chip. There are three options to use it:

* Framebuffer only, using the mailbox protocol (vc4 kernel module not loaded)
* Proprietary driver, replacing system libs ("rpi-userland"): Known to not work properly on aarch64 anyway
* FOSS VC4 driver in mesa: Works well enough for a few OpenGL apps, but unstable

X just needs modesetting, so if vc4 is loaded it just works (tm).
I'm running my RPi3 headless anyway so I just use the first option.

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.

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: 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

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!

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

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

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!