The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

SDL/n2DLib ports for TI Nspire

Started by gameblabla, August 19, 2015, 08:48:31 pm

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gameblabla

April 25, 2016, 06:57:27 pm #255 Last Edit: April 25, 2016, 06:59:03 pm by gameblabla
Ok, it does work pretty well on Nspire with the new ndless so i'm sharing it.
I have fixed the default controls and the relative path issues so just put the game data and the tns file in the same folder
and run it.
https://github.com/gameblabla/wolf4sdl_nspire/raw/master/shareware/wolf3d_nspire.zip

QuoteIt didn't worked on my calc, do I need another binary or somethng with wolf?

Well, make sure to update your ndless_resources with the new one first and reboot your calc.
Then, download the game and run it.

Quote
The issue here is that declaring a struct like that in standard C would cause proper alignment of all members on ARM,
but for some reason it decides to not do it here. Either that's a side effect of "-Os" or some other compiler flag.

Unfortunely, even with -O0, it still doesn't work but maybe GCC is the culprit here.
Any workaround ?

Quote
I doubt it. If it were the same issue, the executable would've run fine on firebird.

Indeed, you are right. In fact, it seems that i have broken it... lol

critor

Quote from: DJ Omnimaga on April 25, 2016, 04:07:24 pm
@Vogtinator I know this isn't relates to Wolfeinstein 3D but do you know how I could check why PicoDrive won't run properly on only my Nspire CX, even though it runs on everyone else's?


You're not alone, DJ Omnimaga. I cannot run any ROM with PicoDrive.
"couldn't load ROM", that's all it's able to tell me. :(

DJ Omnimaga

Oh right, I forgot that you couldn't either. That makes us two. And yes, same error on my end. If only the original author of PicoDrive had error logging.

gameblabla

Quote from: DJ Omnimaga on April 26, 2016, 12:26:50 am
Oh right, I forgot that you couldn't either. That makes us two. And yes, same error on my end. If only the original author of PicoDrive had error logging.

I don't know why you guys have so much trouble with Picodrive...
Actually, Picodrive had some error checks but i had to remove them because it was actually making the Nspire crash. So yeah.

DJ Omnimaga

Yeah, as mentioned before, it could be that our calculators were permanently bricked by another program years ago, or they had faulty hardware in the first place.

The TI-Nspire is not known to be very stable nor have reliable hardware, which is one of the reason why I prefer developing for the TI-84 Plus CE.

* DJ Omnimaga wishes someone made ceSDL (SDL for the 83 Premium CE/84+CE)

rwill

gameblabla,

there is a #pragma pack(1) here:
https://github.com/gameblabla/wolf4sdl_nspire/blame/master/src/wl_def.h#L23

this might lead to severe struct member alignment issues.

gameblabla

Quote from: rwill on April 26, 2016, 05:07:02 pm
gameblabla,

there is a #pragma pack(1) here:
https://github.com/gameblabla/wolf4sdl_nspire/blame/master/src/wl_def.h#L23

this might lead to severe struct member alignment issues.

Yes, you are right, it fixes the alignment issues.
However... it breaks the game in a different way. ( the levels are completely broken in an interesting way with no walls !)

rwill

Well of course it breaks things because Wolfenstein was written for
16bit x86 DOS and the SDL port did not fix all portability issues
that may arise.

Wolfenstein reads complete structures from data files. This is
somewhat like doing, for write and read:

fwrite( &s_struct, sizeof( s_struct ), 1, file );
fread( &s_struct, sizeof( s_struct ), 1, file );

Now if this happens on the same platform or the tool that writes
the structure is _targeting_ a certain platform, where the memory
layout of the structure is known, it is fine. Reading complete
structs or arrays of structs from disk is pretty fast. Imagine
saving a complete program state to disk and then reloading it
to memory and continuing where it left of. Like Hibernation energy
modes on modern PCs.

Sadly - if the memory layout of the structure changes, like what
happens when a structure is changed or alignment requirements of
a platform let the compiler generate different code, this completely
breaks.

So what one normaly does when writing portable code is having
a fixed format of how things are layed out on disk, then reading
the whole chunk of data and then parsing/unpacking it to native
data structures or objects or whatever. One also does need to take
byte order into account. For example network protocols work like this.

Now for your Wolfeinstein port.. I gave it a try and it appears you
need these functions:


uint8_t CAL_read_byte( int handle )
{
uint8_t b;
read( handle, &b, sizeof( b ) );
return b;
}

uint16_t CAL_read_word( int handle )
{
uint16_t w;
read( handle, &w, sizeof( w ) );
return w;
}

uint32_t CAL_read_dword( int handle )
{
uint32_t dw;
read( handle, &dw, sizeof( dw ) );
return dw;
}


void CAL_read_mapfiletype( int handle, mapfiletype *ps_mapfiletype )
{
int32_t i_idx;

ps_mapfiletype->RLEWtag = ( word )CAL_read_word( handle );

for( i_idx = 0; i_idx < NUMMAPS; i_idx++ )
{
ps_mapfiletype->headeroffsets[ i_idx ] = ( int32_t ) CAL_read_dword( handle );
}
}

void CAL_read_maptype( int handle, maptype *ps_maptype )
{
int32_t i_idx;
ps_maptype->planestart[ 0 ] = ( int32_t ) CAL_read_dword( handle );
ps_maptype->planestart[ 1 ] = ( int32_t ) CAL_read_dword( handle );
ps_maptype->planestart[ 2 ] = ( int32_t ) CAL_read_dword( handle );
ps_maptype->planelength[ 0 ] = ( word ) CAL_read_word( handle );
ps_maptype->planelength[ 1 ] = ( word ) CAL_read_word( handle );
ps_maptype->planelength[ 2 ] = ( word ) CAL_read_word( handle );
ps_maptype->width = ( word ) CAL_read_word( handle );
ps_maptype->height = ( word ) CAL_read_word( handle );

for( i_idx = 0; i_idx < 16; i_idx++ )
{
ps_maptype->name[ i_idx ] = ( char ) CAL_read_byte( handle );
}
}


and replace these lines in the CAL_SetupMapFile function:


    //read(handle, tinf, length);
CAL_read_mapfiletype( handle, tinf );



        //read (maphandle,(memptr)mapheaderseg[i],sizeof(maptype));
CAL_read_maptype( maphandle, mapheaderseg[ i ] );

   
Now this does not take byte order into account and is very slow
but anyway..

I noticed that there are things like

char fname[ 13 + sizeof( DATADIR ) ];

which is too small with you appending ".tns", corrupting the stack.

Also it also runs way too fast, did you remove the Timer ? What
if critor overclocks his Nspire to 230mhz and then gets shot by
some SS guy doing over 9000 rounds per minute...

Oh my.

gameblabla

April 27, 2016, 09:04:30 am #263 Last Edit: April 27, 2016, 09:29:21 am by gameblabla
Wow, thanks a lot rwill !
Thanks to you, i always learn something. :)
I can confirm this indeed fixes the issues with the maps, they are now loading properly.

Anyway, updated the game to reflect that and i will put it on tiplanet.

QuoteAlso it also runs way too fast, did you remove the Timer ? What
if critor overclocks his Nspire to 230mhz and then gets shot by
some SS guy doing over 9000 rounds per minute...

I simply disabled a SDL_Delay in the Calctics function because i thought it might slow on nspire
but this turned out not to be the case.
Also, your scenario is unlikely to happen because even at 230mhz, it will be way too slow. :p

EDIT: Ok, done. I also took the time to fix the saves and the configuration file before uploading it to tiplanet.

Grab it here.

Vogtinator

I updated the Ndless SDK and ndless: https://github.com/ndless-nspire/Ndless/releases/latest
Unaligned relocations are now implemented in the "make-prg" loader as well, so it'll run on Ndless < r2005 too.
You need to rebuild your SDK ("make" in the git root) for this to work.

DJ Omnimaga

April 27, 2016, 03:40:14 pm #265 Last Edit: April 27, 2016, 04:52:48 pm by DJ Omnimaga
I'll try the new version of the game to see if it runs on my calculator.


EDIT: Good news, it works flawlessly on my calc :D.

gameblabla

April 27, 2016, 05:20:54 pm #266 Last Edit: April 27, 2016, 06:52:35 pm by gameblabla
Quote from: DJ Omnimaga on April 27, 2016, 03:40:14 pm
EDIT: Good news, it works flawlessly on my calc :D.

Good to know !

However, it seems that some bugs persist.
For example, when you die, a table appears just in front of you. (!)

Probably a side effect of removing the "#pragma pack(1)"...
I'll investigate.

DJ Omnimaga

Aah I see. I tried the game in easy mode so I didn't encounter many enemies. :P

I'll probably make a news about this soon.


Btw @gameblabla : The link to the post about the Sega Dreamcast game you ported to the Nspire is missing from the first post of this topic and some screenshots give 404 not found there.

Vogtinator

Quote from: gameblabla on April 27, 2016, 05:20:54 pm
However, it seems that some bugs persist.
For example, when you die, a table appears just in front of you. (!)

Probably a side effect of removing the "#pragma pack(1)"...
I'll investigate


It was there with packing enabled as well. I thought it was a bed and he simply fell asleep from exhaustion xD

(Don't forget to update your SDK :P)

DJ Omnimaga

According to the TI-Planet news, when you die it can also lead to controls no longer responding (which I assume it means the game freezes, right?)

Also I wonder if we should have a topic for Ndless SDK/C development environment setup support?

Powered by EzPortal