Author Topic: SDL/n2DLib ports for TI Nspire (Read 91456 times)

xlibman · « **Reply #345 on:** December 13, 2016, 11:00:59 pm »

Hm I see. Too bad the speed can't get faster, but again the Jaguar hardware is probably not the easiest to emulate, especially not on a calculator. Good job getting this to work so far

matrefeytontias · « **Reply #346 on:** December 14, 2016, 12:06:08 am »

Nice job on all of those. Again, I'm always happy to see when n2DLib comes in handy to someone.

What's the issue with color masking again ?

gameblabla · « **Reply #347 on:** December 14, 2016, 02:46:37 pm »

Quote from: matrefeytontias on December 14, 2016, 12:06:08 am

Nice job on all of those. Again, I'm always happy to see when n2DLib comes in handy to someone.
What's the issue with color masking again ?

The problem is that there is no easy way to set a color mask with n2DLib.
(without manually attacking the buffer)

Virtual Jaguar uses a color mask to make the framebuffer look right.
Without it, it looks wrong;
It's implemented as such in vj :

Code: [Select]

surface = SDL_CreateRGBSurface(SDL_SWSURFACE, width, height, 16, 0x7C00, 0x03E0, 0x001F, 0);
How could i set a color mask in the buffer ? Any ideas ?

matrefeytontias · « **Reply #348 on:** December 14, 2016, 07:28:13 pm »

You indeed have to touch the image buffer, which isn't a big deal, really. It's basically the same as setting the member of the struct, just with no name on it

This would work for you.

Code: [Select]

inline void setColorKey(unsigned short *src, unsigned short key)
{
    src[2] = key;
}

EDIT : oh wait, you meant a color mask, not a color key. Well that's a bit hard indeed. I didn't have any plan for that since the TI-Nspire screen is R5G6B5, so that would require extra conversion which would be pretty horribly slow anyway ... I think the best solution for you is to write your own updateScreen() based off the existing one. Instead of simply copying the bits, just mask the data using some R5G6B5 to and from RGB transformations (just a couple of bitshifts). But if it is on a per-image basis, then yeah I'm not really sure how to do that except by re-filling the same buffer with the new data (which won't be displayed correctly on-screen by the normal updateScreen() anyway).

gameblabla · « **Reply #349 on:** December 14, 2016, 07:30:11 pm »

Quote from: matrefeytontias on December 14, 2016, 07:28:13 pm

You indeed have to touch the image buffer, which isn't a big deal, really. It's basically the same as setting the member of the struct, just with no name on it This would work for you.
Code: [Select]
inline void setColorKey(unsigned short *src, unsigned short key) { src[2] = key; }

Well, thank you for the function. I did without it tho, it turns out it was just expecting the buffer to be 15-bits so i converted it to 16-bits.

gameblabla · « **Reply #350 on:** April 04, 2017, 07:56:30 pm »

Here's Alterego, a NES homebrew game, ported to the TI Nspire thanks to the bitbox port done by Makapuf.

It's not the NES game running on an emulator, it's the game running natively (through a bitbox wrapper interface).
https://github.com/gameblabla/bitbox-alterego-nspire/raw/master/bitbox-alterego-game/alterego.tns

xlibman · « **Reply #351 on:** April 09, 2017, 04:17:06 pm »

That looks great and fun! Good job gameblabla on the port.

gameblabla · « **Reply #352 on:** April 09, 2017, 06:19:49 pm »

Quote from: DJ Omnimaga on April 09, 2017, 04:17:06 pm

That looks great and fun! Good job gameblabla on the port.

Thx dude :3
I could make it run faster but i didn't want to break compatibility with CR4+ hardware revisions so i didn't.
I need to work on a better n2Dlib that uses the lcd_blit API properly. (Pom1 only supports it partially)

Critor wrote about it here :
https://tiplanet.org/forum/viewtopic.php?t=19820&p=215232#p215232

Thanks as always critor, even though interest in TI-Nspire software has significantly dropped since a few years ago.

critor · « **Reply #353 on:** April 10, 2017, 01:06:55 pm »

Quote from: gameblabla on April 09, 2017, 06:19:49 pm

Thanks as always critor

You're welcome.

Quote from: gameblabla on April 09, 2017, 06:19:49 pm

even though interest in TI-Nspire software has significantly dropped since a few years ago.

I'd rather say interest in TI-Nspire games.
The situation is different on other calculators though, like the TI-84 Plus CE.

xlibman · « **Reply #354 on:** April 10, 2017, 04:52:42 pm »

Yeah I think the constant battle between TI vs Ndless didn't help. The same thing happened with the constant battle between the 68K community vs a certain 68K programmer that shall remain unnamed. It only take one person or organization to alienate everyone else.

gameblabla · « **Reply #355 on:** June 05, 2018, 11:11:07 pm »

Erm..;back somewhat.
I have updated Oswan : it is now compatible with all TI-Nspires : greyscale, CX, CR-4 hardware+ etc...
On firebird; it seems to run somewhat faster than it did on real hardware but i was not able to confirm this yet.
As usual; first post for download.

Let me know if this works properly on your side

gameblabla · « **Reply #356 on:** June 12, 2018, 08:14:39 pm »

After improving my GCW0 port, porting it to the RS-97, i managed to port it to the Nspire too.
A lot of code got stripped : Menu, sound, joystick, config files etc... That allowed me to push more aggressive optimisations than it would allow by default such as decreased size, no rtti, no exceptions etc... A lot of work

It works on Firebird so it should work on real hardware too. Sadly i don't have my Nspire with me rn so please try it on your side if possible.
Of course, you do need the outrun rom files. Extract them in a folder called "roms" and put that tns file relative to that folder.

https://tiplanet.org/forum/archives_voir.php?id=1569330

It's somewhat slow so overc*** your calc if possible.
I admit i haven't tried to switch it to n2DLib yet. That'll come with time i suppose.