[Ported Game] XLogical

[ptitSeb]

Here, you can find XLogical, the classic linux remake of the "Logical" Amiga game.

The port has been adapted to the OpenPandora controls.

You can now move the move with DPad to the nearest Spinner. Then with Space or either Shoulder button you spin it, or with A/B/X/Y button you launch the ball in the direction of the button.

Of course, nubs / touchscreen / mouse is also available, but unless you are suicidal, only real Mouse or the new Keyboard control is recommended.

Hope you'll enjoy it.

Find a few more screenshots:

History log

========

v1.0.0.02

------------

 * Added missing lib (xcb is not in firmware)

v1.0.0.01

------------

 * Initial release

 * based on latest sourcecode

 * added Pandora controls

 

[Neelix]

I can't start it.

Here's the pndrun.out:

Spoiler

=======================================================================================
PND : /media/PND-DATA/pandora/menu/xlogical.pnd
PND_FSTYPE : Squashfs
APPDATADIR : /media/PND-DATA/pandora/appdata/pndmanager
APPDD_FSTYPE : vfat
PND_CPUSPEED : <unset>
EXENAME : scripts/xlogical.sh
ARGUMENTS : <unset>
=======================================================================================
[ START ]--- Mount the PND ----------
Mounting : mount -t squashfs -o ro "/dev/loop3" "/mnt/utmp/xlogical"
Mounting the Union FS : mount -t aufs -o exec,noplink,dirs="/media/PND-DATA/pandora/appdata/xlogical=rw+nolwh":"/mnt/pnd/xlogical=rr" none "/mnt/utmp/xlogical"
[SUCCESS]--- Mount the PND ----------
[ START ]--- Starting the application (scripts/xlogical.sh ) ----------
./bin/xlogical: error while loading shared libraries: libxcb.so.1: cannot open shared object file: No such file or directory
[ FAILED]--- Starting the application (scripts/xlogical.sh ) ----------
[ START ]--- Restoring the frame buffer status ----------
[SUCCESS]--- Restoring the frame buffer status ----------
[ START ]--- uMount the PND ----------
[ START ]--- Waiting the Union to be available ----------
[SUCCESS]--- Waiting the Union to be available ----------
auplinklink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
rmdir: failed to remove `/mnt/utmp/xlogical': Device or resource busy
[ START ]--- Waiting the PND mount dir to be free ----------
[SUCCESS]--- Waiting the PND mount dir to be free ----------
cleanup done
[SUCCESS]--- uMount the PND ----------
=======================================================================================
Return code is : 4

- Neelix

 

[mcobit]

You should really check for all libs before uploading


Nice game.

 

[ptitSeb]

:wacko:  I removed that libs from the PND (to gain space) because I though that version wasn't needed .

I'll repackage soon.

 

[ptitSeb]

It's done. New version on the repo.

I tried without libs from codeblock accessible, and it worked. So that should be good now.

v1.0.0.02

------------

 * Added lib so the PND start.

 

[Neelix]

Works just fine now.

I can see this could get addictive

- Neelix

 

[ptitSeb]

Thank you for the report

 

[Monkfish]

looks fun, also looks like it could get brain-bendingly difficult. i look forward to playing.

 

[jorlinn]

Great port, enjoying it (and some memory lanes from 2000

Loving the mods playing on the background. Makes me feel a pang of regret for not buying the Amiga when it was still around in it's old style in the times that I still had much more time for gaming...

== Controls ==

I like the way how you mapped the abxy-buttons to the launching of the balls; those buttons bear a striking resemblance to the spinners. It does take some getting used to as this kind of action is usually reserved to the dpad. Another option that would also work is to map the selection of the spinners to one of the nubs and the releasing of the balls to the dpad. Just a matter of preference I guess.

Please, use the [start] button instead of [Esc]. Having to push a combination key (Fn) to start the game is just too fiddly. It feels so unnatural to *start* a game with Esc instead of terminating it.

Other fine candidates for this function would be [space], [Enter] and ( B ).

== Pointers for improvement / bug reports ==

One major niggle is the way you switch between spinners. On the fourth level "Stone Road", when I have selected the middle-right spinner and I press Down on the dpad, I expect the spinner which lies directly below it to get selected, when instead I find out that the spinner on the top-right is selected. this makes later levels a major hassle.

Furthermore, the mouse cursor is not visible enough. If I were you I'd opt for a highlight of the selected spinner instead of showing the mouse cursor by increasing the lightness of the spinners and maybe the balls.

This both eliminates the need for mouse cursor visibility and improves the visual cues greatly. Of courses this does mean that you would forgo mouse control altogether. The touchscreen is terribly impractical for the way Xlogical usually works; by mapping the spinning of the wheels to the right-butting and the releasing of the balls to the left-button, since the stylus does not have a quick way to right-click.

== Passwords ==

The original game had a "Last Password" screen, right after you have quit the playing field. Please implement that, because the marquee on the top is simply too small to read in the heat of the game.

= Crashes/ unusual exits =

Asking for a password from the menu by ( B ) instead of [Enter] crashes/ exits to desktop. Tested on the level with the name "Real Fun"

The same goes for the Options menu.

Due to the way that the gamer is handicapped with less then optimal controls, I would appreciate an adaption of the original timing values. Else, levels (especially the ones with a limited ball-rolling time) will get too difficult to stay fun to play.

 

[ptitSeb]

I will take a look at level 4. The way you describe it, it looks like there is a bug in the code that select the spinner.

About the nubs... I didn't touch them, and don't try to read Joystick (that would probably be the most practical way to use them), but that would invalidate Nubs as mouse... So I don't know.

About lighting the selected Spinner. That is a good idea, but I have to see if I am able to do that, I suspect it will require substantial code to be added.  

And thanks for the positive feedback   .

 

[ptitSeb]

About the ESC key... I haven't change the graphics or text, but when it says ESC, you could press Start, I had mapped (unless I had miss one) Start and ESC to do the same.

I have change one of the graphic, at the beginning, so it says "PRESS (Start) to START" now.

About Spinner Selection, yes, I understand now what is the problem. It is not a bug in fact, but the way I look for the spinner is not the good one, so I have to redo it:

Depending on the direction, I set a dx a dy variable. For example, to go up, you set dx=0, dy=-1. Then I look at x+dx and y+dy. If it's a spinner, ok, I have found it and stop searching. Else, for the "go up" example, I search the nearest in the line, where in fact, I should search the entire row for another spinner, and than try left/right.

So I will try to correct that.

About the spinner lighting, I'm not sure yet how to do it...

 

[jorlinn]

About the ESC key... I haven't change the graphics or text, but when it says ESC, you could press Start, I had mapped (unless I had miss one) Start and ESC to do the same.

I have change one of the graphic, at the beginning, so it says "PRESS (Start) to START" now.

Ah, and I didn't even try..., how lazy of me

About Spinner Selection, yes, I understand now what is the problem. It is not a bug in fact, but the way I look for the spinner is not the good one, so I have to redo it:

Depending on the direction, I set a dx a dy variable. For example, to go up, you set dx=0, dy=-1. Then I look at x+dx and y+dy. If it's a spinner, ok, I have found it and stop searching. Else, for the "go up" example, I search the nearest in the line, where in fact, I should search the entire row for another spinner, and than try left/right.

So I will try to correct that.

That would be great! I'd love to see that corrected.

I would go for the following algorithm (in plain speech that is:

When tapping a dpad direction, first look for a perfect match in that direction (for instance when tapping UP look if there is a spinner directly above the currently selected one. If none are available, select the spinner that is situated higher then the current one, with the smallest d(other axis) from the current one. When two are available opt for the one that is leftmost or bottommost (following the logic of reading from left to right and from top to bottom). Some scripts are written from right to left instead, so maybe you should provide an option to switch that preference. On the other hand, this game seems to be orientated just the other way around, since the balls will originate in the right side of the gutter, rather than the left side.

Another thing that would really work for me is to have the selection of the spinner home in on the top right spinner that is connected to the gutter, every time a playing field starts. It it is the most logical place to home into, since that would be the first spinner that can receive balls.

About the spinner lighting, I'm not sure yet how to do it...

What library are you using for the graphics? If it's OpenGL like the original XLogical, applying an increase in lightness while keeping the alpha channel untouched would be a simple matter to cause the selection highlighting .Note that this does have a downside, because the colors become less distinct from each other, effectively bleaching them. Maybe you should leave the balls untouched for that reason, highlighting only the spinners themselves.

If it's SDL, than it's a different case... In that case you would need a separate graphic/ sprite for the selected and the unselected states of the spinners and the balls.

Another thing, on the instruction page it shows that you can select another mod track with left and right, but those controls conflict with current functions of both the dpad and the shoulderbuttons. I'd map that one to the [M] button, since it is the first letter of both Music and Mod.

 

[ptitSeb]

About Spinner Selection, yes, I understand now what is the problem. It is not a bug in fact, but the way I look for the spinner is not the good one, so I have to redo it:


Depending on the direction, I set a dx a dy variable. For example, to go up, you set dx=0, dy=-1. Then I look at x+dx and y+dy. If it's a spinner, ok, I have found it and stop searching. Else, for the "go up" example, I search the nearest in the line, where in fact, I should search the entire row for another spinner, and than try left/right.


So I will try to correct that.

That would be great! I'd love to see that corrected.
I would go for the following algorithm (in plain speech that is:


When tapping a dpad direction, first look for a perfect match in that direction (for instance when tapping UP look if there is a spinner directly above the currently selected one. If none are available, select the spinner that is situated higher then the current one, with the smallest d(other axis) from the current one. When two are available opt for the one that is leftmost or bottommost (following the logic of reading from left to right and from top to bottom). Some scripts are written from right to left instead, so maybe you should provide an option to switch that preference. On the other hand, this game seems to be orientated just the other way around, since the balls will originate in the right side of the gutter, rather than the left side.


Another thing that would really work for me is to have the selection of the spinner home in on the top right spinner that is connected to the gutter, every time a playing field starts. It it is the most logical place to home into, since that would be the first spinner that can receive balls.

>About the spinner lighting, I'm not sure yet how to do it...

What library are you using for the graphics? If it's OpenGL like the original XLogical, applying an increase in lightness while keeping the alpha channel untouched would be a simple matter to cause the selection highlighting .
Note that this does have a downside, because the colors become less distinct from each other, effectively bleaching them. Maybe you should leave the balls untouched for that reason, highlighting only the spinners themselves.


If it's SDL, than it's a different case... In that case you would need a separate graphic/ sprite for the selected and the unselected states of the spinners and the balls.


Another thing, on the instruction page it shows that you can select another mod track with left and right, but those controls conflict with current functions of both the dpad and the shoulderbuttons. I'd map that one to the [M] button, since it is the first letter of both Music and Mod.

About the music, I already mapped previous / next to other key (P and N), but I didn't update the instruction page. I'll do it.

The graphics are done using SDL.

About the mouvements, I still haven't figured out a good scheme for that. There can be some tricky things, as the scheme must allow all spiner to be reached.

For example, a layout like this:

()      ()
    ()
()      ()

if you first choose the direct path, you can never reach the midle one...

 

[Linux-SWAT]

I have no idea how to play this game ^^.

 

[jorlinn]

About Spinner Selection, yes, I understand now what is the problem. It is not a bug in fact, but the way I look for the spinner is not the good one, so I have to redo it:


Depending on the direction, I set a dx a dy variable. For example, to go up, you set dx=0, dy=-1. Then I look at x+dx and y+dy. If it's a spinner, ok, I have found it and stop searching. Else, for the "go up" example, I search the nearest in the line, where in fact, I should search the entire row for another spinner, and than try left/right.


So I will try to correct that.

That would be great! I'd love to see that corrected.
I would go for the following algorithm (in plain speech that is:


When tapping a dpad direction, first look for a perfect match in that direction (for instance when tapping UP look if there is a spinner directly above the currently selected one. If none are available, select the spinner that is situated higher then the current one, with the smallest d(other axis) from the current one. When two are available opt for the one that is leftmost or bottommost (following the logic of reading from left to right and from top to bottom). Some scripts are written from right to left instead, so maybe you should provide an option to switch that preference. On the other hand, this game seems to be orientated just the other way around, since the balls will originate in the right side of the gutter, rather than the left side.


Another thing that would really work for me is to have the selection of the spinner home in on the top right spinner that is connected to the gutter, every time a playing field starts. It it is the most logical place to home into, since that would be the first spinner that can receive balls.

>About the spinner lighting, I'm not sure yet how to do

it...

What library are you using for the graphics? If it's OpenGL like the original XLogical, applying an increase in lightness while keeping the alpha channel untouched would be a simple matter to cause the selection highlighting .
Note that this does have a downside, because the colors become less distinct from each other, effectively bleaching them. Maybe you should leave the balls untouched for that reason, highlighting only the spinners themselves.


If it's SDL, than it's a different case... In that case you would need a separate graphic/ sprite for the selected and the unselected states of the spinners and the balls.


Another thing, on the instruction page it shows that you can select another mod track with left and right, but those controls conflict with current functions of both the dpad and the shoulderbuttons. I'd map that one to the [M] button, since it is the first letter of both Music and Mod.

About the music, I already mapped previous / next to other key (P and N), but I didn't update the instruction page. I'll do it.

The graphics are done using SDL.

About the mouvements, I still haven't figured out a good scheme for that. There can be some tricky things, as the scheme must allow all spiner to be reached.

For example, a layout like this:


()      ()
    ()
()      ()



if you first choose the direct path, you can never reach the midle one...

I agree. In this case I would interpret the middle spinner as if it was in the middle between the two bottom spinners. Why the bottom ones and not the top ones? The top ones are connected to the gutter and should be reachable in the most logical way. That should take absolute precedence imo.

Furthermore I am more adaptable to horizontal jump then to vertical jumps behaving a little off, but that may just be my personal preference. I d love to chat about this some time during the weekend or so if you have the time.

 

[ptitSeb]

I think I have a working scheme in mind. I try to program it, but I have to debug a bit, and not beeing at home, I don't have my computer with SSH (to kill XLogical when stuck in an infinite loop).

Initially, I didn't wanted to have "global variable", but I finnaly created two. the "old_row" and "old_column" selected.I try to explain in a few word (not my specialty, words), when, for example, you press Left, I'll try to find the first sprinner starting from curent position.. I eventually find one. Nice. Let's say you repress left. I, again, try to find the first spinner at the left, but the "starting row" for the search is the old one. So with that, when you are on top right, in the "5" layout, with 2*Left you are in Top Right.

When you use a Spinner (rotate or launch a ball), the "old" value are set to current... I hope to have this implemented soon.

 

[jorlinn]

Great, ptitSeb, I can't wait to test this in practice. Please give me a PM when it's ready.