Hi all,

I got a request for assistance via mail and could not help further.

The problem the person is having is that the transfer of a file fails with a message from the
Link software that "An unsupported file was encountered. Only TI-Nspire (.tns) files may be
sent to a connected handheld.".

The file in question is pak0.pak.tns for quake.

Now as it used to work for me with version 3.9.0.455 of the link software and OS 3.6 I wonder
if TI added something to later versions which prevent certain files to be sent to the Nspire, or
if this could be caused by something else or if anyone here already encountered this error
too and knows the cause.

This appears to be a form of https://en.wikipedia.org/wiki/Arithmetic_coding

If your model is static, you want good sorting, cannot afford a Z-Buffer, and can live with
a higher polygon count you might want to apply Binary Space Partitioning to a model and
render accordingly.

But really, the way to go is to keep sorting problems in mind when creating the model,
maybe making manual splits of large polygons and keep parts of the model kind of convex.
I remember that a lot of the first 3D Games had sorting problems.

You really should apply backface culling.

Quote from: DJ Omnimaga on April 30, 2016, 04:01:10 PM
What's the minimum stack size required by nQuake?

Well I can only guess but it worked with around 56k. Unmodified WinQuake was around 600k...

Quote from: Lionel Debroux on April 30, 2016, 08:23:44 AM

QuoteI do not use high warning levels and/or static analyzers - they give a false sense of security.

I feel that not using them and hiding important warnings gives a worse false sense of security, though

Well at least I know that there isn't an automatic tool holding my hand when writing code.

So I tried running nQuake with a new ndless and it appears that
the usable stack size shrunk to around 53kb. This makes nQuake
crash. As 53kb is somewhat low for any program I wondered if it
would be possible for ndless to increase the amount of stack
available to programs, most likely by pointing the stack to
an ndless allocated region and then restoring the real stack
when entering syscalls.

I can wrap the syscalls myself for nQuake but nQuake can hardly
be the only application where such a small stack size is
a problem..

Quote from: gameblabla on April 28, 2016, 07:01:46 PM
Just how rwill you can spot issues like this ?
I didn't even know GCC's optimisation was that aggressive !

It works properly now so congrats rwill.

Well I checked what happens in the player death function Died()
and could not spot where it spawns a table. I saw the assignment
of -1 to gamestate.weapon in there though and remembered that
GCC is sometimes doing questionable things when optimizing
as -1 was missing in the weapontype enum. Seeing that
gamestate.weapon was used as an index into an array that
determines what gets drawn as the active weapon then kind
of solved the issue already.

Sometimes you can try to build without optimizations to see if the
problem goes away. If it does it is most likely a
programmer <-> compiler issue. Debugging by inserting printf()s
at certain places in the code can help too, especially when running
without debugging symbols at a high optimization level.

I do not use high warning levels and/or static analyzers - they
give a false sense of security. For example even with trying I cannot
get gcc to spit out a warning at the lines in question in the wolf code
so....

Quote from: Vogtinator on April 27, 2016, 05:57:45 PM

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 )

Well...

there are things like this in the source:

gamestate.weapon = (weapontype) -1;                     // take away weapon


Now gamestate.weapon is of enum type weapontype which does not specify -1 as a valid enum. GCC being pedantic as always probably uses this as an excuse to let checks like gamestate.weapon != -1 being true. For the specific case that something wrong is drawn there is this:

    if (gamestate.weapon != -1)
    {
        shapenum = weaponscale[gamestate.weapon]+gamestate.weaponframe;
        SimpleScaleShape(viewwidth/2,shapenum,viewheight+1);
    }


If the if() gets optimized to true always shapenum is something read at weaponscale[ -1 ] plus whatever.

gameblabla, see if changing the lines around 830 in wl_def.h to the following helps:

#define NUMWEAPONS      4
typedef enum
{
    wp_none = -1,
    wp_knife = 0,
    wp_pistol = 1,
    wp_machinegun = 2,
    wp_chaingun = 3
} weapontype;


The correct way would be to always use the enum names and never a numeric value.

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,

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.

I just tried to log in and my password was not accepted so I had to reset it... ?

It says one their page it has this:
www.allwinnertech.com/en/clq/R_series/2015/0514/R8.html
Of course it has a GPU, youd think theyll let your browse Facebook over some terminal in Lynx ?

Regarding the type of login problems, Art_of_camelot made a thread about it and he had the same symptoms as I had, it just hangs on the loading part. It may only happen on the first login after the security update was deployed, it happened on my first login after the update and he created the thread 5 minutes after that. I do not know if it was his first login after the security update, one might need to ask him if one wants to investigate in this direction further. I did look at what I POST to the server on login and besides some 20kb hashed_paswd in the form, where I do not know where it comes from, I noticed nothing out of the ordinary and had no problems ever besides the one time after the security update. Ah well, good luck.

And hopefully unrelated, I got this email directing me to this thread:


Subject: rwill, you have been mentioned at a post in CodeWalrus
Hello rwill!

DJ Omnimaga mentioned you in the post "Sorunome, you have been mentioned at a post in CodeWalrus", you can view the post at https://codewalr.us/index.php?msg=28835

Regards,
CodeWalrus

While the Sorunome part is certainly not his post title I think.

Last post Nov 28, but I see the need to reply anyway...

For television/broadcast there is 720p ( sometimes called HD Ready ) and 1080p/i ( HD ) and 2160p ( UHD ).

For cinema there is mostly 2k and 4k with _various_ vertical resolutions and sometimes adjusted horizontal resolution.

I will not comment on the use of the term "4k" when used for consumer devices but I suggest to read the wikipedia entry for the 4k resolution. The german wikipedia entry for 2k https://de.wikipedia.org/wiki/2K_(Film) has an interesting resolution table for digital cinema as well.

PS: My password was rejected ~3 times when logging in to CW, then it worked. I did not make a mistake typing because I used copy/paste.

@gbl08ma

Interesting... when I try almost all possible combinations heatshrink allows for window and length for back references on each file of the Canterbury Corpus and pick the smallest result for each heatshrink comes out at around 880kb for all 11 files at best. Doing it this way takes some time though. As you already noted, picking the same settings for all files is far from optimal. Sadly I cannot test the same approach with my modified deflate or the official gzip as these lack such tuning parameters. Given the Canterbury Corpus files they come out smaller in all cases though.