Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rwill

Pages: [1] 2
1
TI-Nspire / Re: SDL ports for Nspire
« on: September 05, 2015, 12:03:20 pm »
Hi gameblabla,

it is not really simple to write a graphics output module for ScummVM as it is designed to run on very different platforms so the amount of abstraction the graphic module has to cover is quite high. I would guess that copying the ScummVM SDL graphics driver and replacing the SDL calls with something more native might be the quickest way. There are documents and hints available what does what, start here: doxygen.scummvm.org/d9/df4/classOSystem.html

As it appears that you are kind of overloading yourself with emulator ports - it might be wise for you to buy some small server device on which you can install Git or Subversion, like a Raspberry PI + Flash Drive for example, to do local development and version control if you have not already. Just to keep things organized...

2
TI-Nspire / Re: SDL ports for Nspire
« on: September 04, 2015, 02:58:48 pm »
Hi gameblabla,

try this, please report back.

3
TI-Nspire / Re: SDL ports for Nspire
« on: September 04, 2015, 12:43:16 pm »
Hello,

I noticed that critor still has problems loading saved games in ScummVM. gameblabla, are you sure that you build from the right source and did the .h and .cpp modifications ? It works here. You can test save games by pressing the '(' key on the nspire to save a game in scumm games and use the same menu to load one. I can provide a patch against the original 1.7.0 source on request if it still fails.

4
TI-Nspire / Re: SDL ports for Nspire
« on: September 03, 2015, 04:34:02 pm »
Hi gameblabla,

I noticed that save games are actually not working with scummvm on the nspire. I also just got your PM ( I do not log in when checking forums for activity so I rarely see them in time ).

Anyway you could try to change the following lines in \backends\fs\nspire\nspire-fs.h to
Code: [Select]
virtual bool exists() const;
virtual bool isReadable() const;
virtual bool isWritable() const;
like remove the function body after the const and implement them like so in \backends\fs\nspire\nspire-fs.cpp:
Code: [Select]
bool NspireFilesystemNode::exists() const {
Common::String str = _path;
if( !_isDirectory && !str.hasSuffix(".tns" ) )
{
str += ".tns";
}
return access(str.c_str(), F_OK) == 0;
}

bool NspireFilesystemNode::isReadable() const {
Common::String str = _path;
if( !_isDirectory && !str.hasSuffix(".tns" ) )
{
str += ".tns";
}
return access(str.c_str(), R_OK) == 0;
}

bool NspireFilesystemNode::isWritable() const {
Common::String str = _path;
if( !_isDirectory && !str.hasSuffix(".tns" ) )
{
str += ".tns";
}
return access(str.c_str(), W_OK) == 0;
}

The idea is that file access is wrapped in a way that scummvm does not know about the .tns suffix except on the lowest level because there appear to be many places in scummvm that expect a file to have a certain name or format.

Just a note, maybe you should distribute the patch or the full source with your binaries, or make them available elsewhere, to honor the GPL.

5
TI-Nspire / Re: SDL ports for Nspire
« on: August 17, 2015, 01:15:46 pm »
try ./configure --help

So for example to enable scumm v1-v6 games and Lure of the Temptress you would pass - among other things - "--disable-all-engines --enable-engine=scumm,lure" to the configure script.

I kind of did not --disable-debug because it was still in development and forgot about it.

I think the scummvm.tns binary you provided is the genzehn version, I suggest to use the backwards compatible scummvm.prg.tns one. Maybe you can also add the keyboard layout picture I made so people know what to press for which key.

Now to get Lure of the Temptress running you need the files listed on wiki.scummvm.org/index.php/Datafiles, please note the lure.dat file you can download there directly. Then it looks like attached in an emulator.

Good Luck.

PS: From a technical standpoint RoQ is far from similar and quite inferior to MPEG-1 Video.

6
TI-Nspire / Re: SDL ports for Nspire
« on: August 15, 2015, 06:25:51 pm »
Soooo....

after an unfortunate accident involving a water bottle and a Ti-Nspire ( its really hard to remove a non removable battery to prevent looming liquid damage ) I am kind regretting to not pick up multiple "rootable" Nspires when I had the chance.

Anyway - as some people are kind of interested in scummvm on the Nspire all I can do now is release a patch against the scummvm 1.7.0 source. Just copy it into the scummvm-1.7.0 directory and apply it in a Unix environment ( cygwin will do ) with the patch tool like "patch -p2 < scummvm-1.7.0_nspire.patch" and then compile with the buildme.sh script. The patch is rather small as I just did not get around replacing SDL for graphics with something native ( Yeah I lost interest ). I also strongly recommend to only enable the old scumm games as otherwise the executable is quite large and the games it supports are even larger. There are also some printfs in the code, not all are mine.

I kind of figured out some key binding that might work but its not emulator friendly, see attached picture.

You will need to create a folder on the Nspire and copy scummclassic.zip, scummmodern.zip and translations.dat to this directory, next to the executable.

You will also need SCUMM games ( Monkey Island ! ) which each should go into its own directory, possibly inside the scummvm main directory. Please do not try to use CD game version as then timing gets sometimes screwed up because the compressed CD tracks are actually not there or can not be decoded.


I will monitor here for question and - gameblabla you are our only hope !

7
TI-Nspire / Re: SDL ports for Nspire
« on: July 16, 2015, 04:40:47 pm »
Regarding ScummVM, its running and is now only using nSDL for graphical output, everything else is bolted to the Nspire hardware ( ok, its only timing, null sound and input ). Now this state was already done when I made the post in question, then "real life" got in the way.

So graphics still need to be replaced with something Nspire native as nSDL is "not so good". There also needs to be a valid key mapping from Nspire -> ScummVM games so games can actually be played and finished. ScummVM supports a lot of games and it appears there is no list of keys which are a required baseline to match them all. In addition I also do not have all games supported by ScummVM available to test.

It would be kind of a bad style to do a release and then have someone come up and say "It wants you to press this key but this key is not available on the NSpire ?". This would be a really significant sign of a rushed release, something that plagues certain PC game releases also ( real game breaking bugs ) and I rather go slow and mostly correct than go "Hey it shows the Intro and Menus, I am done".

8
TI 68K / Re: Delsgolf (TI-89) Update
« on: July 06, 2015, 02:56:14 am »
Well with the 1.02 Delsgolf release on ticalc I will let it rest for a while again. I am currently working on a scene demo for the TI-89 and am trying to do a proper port of ScummVM for the Nspire. The most significant problem with all that is that the day only has 24 hours and the week only 7 days - I am quite busy elsewhere and sadly cannot spend as much time on calc programming then I would like to.

9
TI-Nspire / Re: New TI-Nspire emulator: Firebird Emu
« on: June 08, 2015, 07:42:18 am »
Thanks to the Team for improving the Nspire Emulator.

The new on screen keyboard is really well done.

I compiled it myself from source on win32/mingw and noticed two things:

After startup of the OS, when left-click dragging around the touchpad on the on screen keyboard, the emulator might display "Invalid mode 0x0" and then no more input is accepted. Sometimes no more input is accepted without the display of the error message.

The emulated timer hardware appears to match the % emulation speed display, so it is off by some factor. I tested with some projects of mine and its most noticeable in nQuake when doing timedemo runs ( timedemo says the playback needed N seconds but in real time it took around N * 1.45 seconds ).

10
TI-Nspire / Re: SDL ports for Nspire
« on: June 01, 2015, 03:51:16 pm »
What game is that?

It is Monkey Island, released in 1990. Thanks for making me feel old.

11
TI-Nspire / Re: SDL ports for Nspire
« on: June 01, 2015, 03:38:24 pm »
Did someone say SDL ports ?

12
TI 68K / Delsgolf (TI-89) Update
« on: May 24, 2015, 11:14:37 am »
I have somewhat recently started to optimize Delsgolf ( that first person shooter for the TI-89 ) again and want to release it now to a more wider audience than myself. Delsgolf now also has some sort of sound ( link port stereo, like polysound ) and the data file has a slightly smaller size. The game assets ( map, textures, etc ) have remained unchanged.

I have attached a release candidate to this post.

If you want to know what you are getting with Delsgolf, the older version with a slightly more verbose description is still here: www.ticalc.org/archives/files/fileinfo/457/45704.html

I would also be very happy if someone could tell me how to not make Ti-Emu screw up the screen because of grayscale emulation, as can be seen in the ticalc link animated screenshot.

13
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: May 22, 2015, 11:45:56 am »
... 32-bit access ...

I have not checked but later versions of GCC should be able to produce code for ARM that will use 32 bit moves if possible given my example function. Thinking about it further - the function might be made faster by doing 2 lines at the same time inside the inner copy loop. Ah well, "high level" optimizations...

14
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: May 20, 2015, 10:08:15 am »
Ah .. might as well be more specific and direct ..
Code: [Select]
void blit_pels( const int16_t *pp_srcB, int32_t i_src_stride, int16_t *pp_dstB, int32_t i_dst_stride, int32_t i_width, int32_t i_height )
{
int32_t i_y;
for( i_y = 0; i_y < i_height; i_y++ )
{
int16_t pp_a0, pp_a1, pp_a2, pp_a3;
const int16_t *pp_src;
int16_t *pp_dst;
int32_t i_remain4, i_remain1;

pp_src = pp_srcB;
pp_dst = pp_dstB;

i_remain4 = i_width >> 2;
while( i_remain4 > 0 )
{
pp_a0 = *( pp_src++ );
pp_a1 = *( pp_src++ );
pp_a2 = *( pp_src++ );
pp_a3 = *( pp_src++ );
*( pp_dst++ ) = pp_a0;
*( pp_dst++ ) = pp_a1;
*( pp_dst++ ) = pp_a2;
*( pp_dst++ ) = pp_a3;
i_remain4--;
}

i_remain1 = i_width & 3;
while( i_remain1 > 0 )
{
pp_a0 = *( pp_src++ );
*( pp_dst++ ) = pp_a0;
i_remain1--;
}
pp_srcB += i_src_stride;
pp_dstB += i_dst_stride;
}
}


There might be some gain to increase the unroll block to 8 pixels instead of the 4 but I did not bother to even test this one here.

15
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: May 18, 2015, 03:40:58 pm »
Shorter is not *edit* always */edit* faster. Especially given the ARM9EJ-S core.

*edit*

Given your example, which seems to copy without the transparency check, we end up with something this ( cycle estimate at end of line ):

Code: [Select]
loop:
ldrh r3, [r0], #2   | 1
strh r3, [r1], #2   | 2-4 ( 2 cycles of 2 cycle interlock on r3 )
cmp r0, r2     | 5
bne loop            | 6-8

So, for example, unrolling the loop would help quite a bit.
8 Cycles for copying a single pixel without any transformation is way too much.

Pages: [1] 2