Xandoz by Graham T.

[hcmffm]

@Graham T. said:

New game released for beta testing: gtoal.com/vectrex/xandoz/Xandoz.bin play using the buttons. (Use the joystick only for menu selections which you can play without ever needing; activate a menu selection with the right hand button.) Please post constructive feedback on the UI. I think the game logic is correct and unlikely to be improved on by me. (ie I won't be adding lookahead/minimax) You can beat it every time once you've learned how but it should take a bit of effort to get there. (btw if you have already downloaded a bin and it doesn't print a version number BETA0.3 at startup, fetch it again please.)

A video of Xandoz:

[hcmffm]

Feedback for Xandoz

Game version: 0.3

Platform: Emulator ParaJVE

Good:
+ Self-explanatory. Instructions appear when doing nothing for a short while.
+ Various feedback "Whew" / "Nice" depending on your move.
+ Computer is not too simple to beat (Until now, I've played four times and lost every time).

Suggestions & Ideas


Joystick support
Currently, you can control your "cross" using buttons, only.
Suggestion: Support joystick navigation. Joystick should move X/Y by default.

I wonder how moving Z using the joystick could be added. Two ideas:
a.) Keeping one of the buttons 1-3 pressed the Y moving could become Z moving
b.) Whenever "leaving" the grid the cursor could move one level down/up. E.g. when leaving on the front/right it could move a level down and when leaving on the back or left side it could move a level up).

Note: Personally, I like b.). Perhaps other people have an even better idea for Z moving.


Most left Button = Right
Currently, the very left button 1 moves the "cross" to the right. This feels a bit unintuitive.
Suggestion: Button 1 should move cursor to the left.

Button down = Cursor up
Currently, when pressing button 3 down the cursor will move one level up. Again, this feels a bit unintuitive.
Suggestion: Button 3 should move to cursor one level down.


New move: Hard to see
Currently, it's a bit hard to see were the computer has set his move.
Suggestion: Let the computers square blink for a short while.

New move: animation
Idea: In "real" TicTacToe you draw crosses and circles or similar. Perhaps an animation could be added which shows the drawing of cross and rue. E.g. a laser beam from above could burn the new cross/rue into the board. (Somehow "Battle Chess" comes to my mind )

"I move to 414"
Currently, the computer says something like "I move to 414". At first, one has no idea what this means.
Suggestion: Improve visibility of computer's move (see previous issue). Then, the exact (technical) coordinates will no longer be neeeded and text can be changed to something like "I moved. Your turn."

Menu "QUIT"
Currently, there's a menu item "QUIT". This sounds as if you could quit the app and return to the Vectrex desktop to start other apps.
Suggestion: A label like "NEW GAME" or "RESIGN" might be better than "QUIT".

Whirl/Tumble/Flip/...
Currently, in the menu you have many options to change the game board. I'm not quite sure but from what I can see this is just a change in the perspective to the game board.
ATM, I'm not sure whether all these functions to change the perspective of the game board are really helpful when playing or not.

"X Y Z PLAY"
Currently, when pausing for a longer time a text "USE THE BUTTONS: X Y Z PLAY" appears. "PLAY" sounds like what you do all the time.
Suggestion: Perhaps use a different term instead of "PLAY". E.g. "SET". Please note that I'm not a native speaker.

End of game
Currently, at the end of the game the match is shown and a bright line is drawn.
Suggestion: The line should be dimmed while the rest can remain bright. A dashed line might be even better - this way the match line and the grid can be distinguished more easily.

Square cells
Currently, the "cells" in the grid do not look square.
Suggestion: Board might look better if the "cells" were square (i.e. the grid should be wider)

Sound?!
Xandoz is a game of thinking and patience. So it's good that no enerving background music is played.
Currently, there is no sound at all.
Suggestion: Add some simple sounds on some events. E.g.
.. when cursor is moved into another "cell". (X, Y, and Z movements could have different tones).
.. when computer "calculates" its move
.. when computer wins
... when player wins

Round counter
Idea: For the player it might be interesting to know how fast he/she was beaten or he/she has beaten the computer. A round or move counter could be a good information.

Instructions "USE OF BUTTONS:"
Idea: "Instructions" might be even clearer when displaying them like this:

USE THE BUTTONS:

1   2   3   4
|   |   |   |
X   Y   Z  PLAY

[gtoal]

Thanks. All good advice. I'm going to take a week off from hacking on this (it's three solid nights of work, starting around 11pm and finishing around 4am!) and come back to it after reading all the feedback and with a fresh view.

[hcmffm]

Thank you for your prompt feedback, gtoal. Amazing, that you've programmed the game in just three night session. I guess the days were pretty tough, then.

Above I've just added some more suggestions & ideas. A good joystick support will improve the game quite a bit, I think.

[gtoal]

Just FYI if you look at the source ( gtoal.com/vectrex/xandoz/xandoz.c.html ) you'll note that I have indeed tried to add some sounds, I just was unsuccessful. (Haven't ever done sounds on the Vectrex before). Btw I'm quite open to contributions :-) (of code I mean, in case that was ambiguous!)

[Peer]

I can help with the sound. The BIOS sound routines are a bit limited, but they are much better than their reputation might be. Especially the explosion effects one can achieve are really good. And the routines are pretty easy to use once you know how to do it. From C, you do not need any inline assembly, just calls of the BIOS routines, and the sound data in the correct format. I also have wrapper functions and struct types ready for this. I am travelling right now and I do not have access to my code, but I can send you the code and an example how to use this on Sunday evening if you like. Just let me know, and enjoy your coding break

Cheers,

Peer

[gtoal]

Oct 3, 2019 0:55:39 GMT -5 Peer said:

I can send you the code and an example how to use this on Sunday evening if you like. Just let me know, and enjoy your coding break

That would be great, Peer.  Thanks.

[D-Type]

Oct 3, 2019 6:16:00 GMT -5 gtoal said:

Oct 3, 2019 0:55:39 GMT -5 Peer said:

I can send you the code and an example how to use this on Sunday evening if you like. Just let me know, and enjoy your coding break

That would be great, Peer.  Thanks.

I'd be happy to see that also, Peer. I've never done any sound either!

[hcmffm]

BTW, for Bloxorz, developers Frank B. and Malban tried various ways to draw the grid efficiently. I'm not sure whether performance is an issue for Xandoz. If yes, you might ask Malban or Frank and find out.

[gtoal]

I've posted an interim update (Beta 0.4) to test out a mechanism for drawing O's as circles. Also I've started incorporating some of the feedback in terms of board shape, which lets me improve the positioning of status/hints. (The board grid doesn't quite join up as perfectly as before but I'll tweak that later. It's not really noticeable unless it's been pointed out. Oops )

Otherwise unless I carelessly blew something up, it ought to play as before.

[hcmffm]

Thank you for the new interim update of Xandoz. I've just tried Xandoz beta 0.4 but It's impossible to play: All "O"s are positioned at the same location. I've tried on three Vectrexes and the same on all of them.

The "O" look o.k. but the "O" looks 2D, i.e. the perspective is wrong (also on all three Vectrexes).

[gtoal]

Oct 5, 2019 8:19:44 GMT -5 hcmffm said:

Thank you for the new interim update of Xandoz. I've just tried Xandoz beta 0.4 but It's impossible to play: All "O"s are positioned at the same location. I've tried on three Vectrexes and the same on all of them.

The "O" look o.k. but the "O" looks 2D, i.e. the perspective is wrong (also on all three Vectrexes).

Ah. Well that's why we beta test :-)  Works in the emulator and on my Vectrex. I've reverted that change until I can work out what may be hardware dependent: the last working version (Beta3) is at gtoal.com/vectrex/xandoz/Xandoz.bin and the one with the circular O's is at gtoal.com/vectrex/xandoz/Xandoz-Beta4.bin  - it would be helpful to know if it is broken for everyone except me or just for a few systems, although the fact that Helmut tested on 3 separate systems doesn't bode well :-(  (Be sure to mention the version number from the startup screen when reporting back please)

I know the shape is wrong, I was just getting the mechanism in place. Had already asked about how to draw ellipses in this thread: vectorgaming.proboards.com/thread/1234/drawing-6522s-shift-register-timer?page=3

Thanks for letting me know.

G

[Peer]

Hi gtoal and D-Type,

I have just sent you a small demo project of how to use the Vectrex BIOS sound routines in C. I hope that I have used your correct email addresses. If you have any questions, please let me know.

Many Cheers,

Peer

[Malban]

Hi,

looking at your code, this section makes me *SHUDDER*:

#define gosub(x,y,func) \
 asm(" lda %0\n"                       \
     " ldb %1\n"                       \
     " ldu -16,s\n"                    \
     " pshu d\n"                       \
     " jsr _drawcirc\n" :                      /* outputs */ \
                        : "g" (x),  "g" (y)    /* inputs */  \
                        : "d", "x", "y", "u"); /* clobbered */

void draw_circle(int x, int y) {
 gosub(x,y,drawcirc);
}

Since I am sort of into Vide - I tried to run you program in Vide - using the default "C" options.

I don't know how you compiled your code - whether you used VIDE or not. But I would really like to nudge you further in the Vide direction.

a) all known compiler bugs have been addressed and are repaired

b) options can be set from the project page - and are saved to the project - so other people can see them. Also it is really easy to change the options

c) you can not only include "asm" statements into the "C" code (as you did), but you can also add complete assembler sources to an existing "C" program, which can be accessed directly

d) documention on how arguments are passed (and examples)

e) debugging - the debugging features (ASM and "C" debugging) really help!

Debugging you code shows with most of my settings, that regisster "U" after the 4th line contains "0" (null) - so pushing things on to U results in something terrible.

What you are probably trying to do with
" ldu -16,s\n"
is to locate 16 "free" bytes on the stack. What you actually do is load register U with the value that is contained in (S-16).
the right "choice" if you want to follow that "bad" coding would be:
"leau -16,s" (which by the way WORKS!)

Having your subroutine stored as "data" statements which are called from the gosub macro, and the data statement being an "extract" of another binary... MAY be possible.... but ... *double shudder*.

I mean - you already disassembled the bin - why not add an assembler source?

Even an assembler source as dunno ... 50 asm()... statements - that way one could at least get a glimpse of the routine?

There is nothing really spectacular about the routine... it first resets to zero (which you already did) - than moves to the location

(y,x) that is pulled from (U).

The actual circle routine follows (from "L05D3" ) - (and resets to ZERO at the end).

But quintessentially...

The circle uses "fixed" values and "pokes" repeatedly to the VIA A/B registers, which could also be done in "C".

(pseudo code):

drawCircle(int y, int y)

{

  Reset0Ref();

  MoveToD(y,x);

   

  // starting from "L05D3"

  dp_VIA_Aux_cntl = 0;

  dp_VIA_port_b = 0x80;

  dp_VIA_port_a = 0xF6;

  ...

  //up to

  dp_VIA_cntl = 0xcc;   // which is a "Reset0Ref"

 

  circle is done here...

  //reset Aux Value:

  dp_VIA_Aux_cntl = 0x98; 

  // rest of the code is

  // some mumbo jumbo - probably to ensure stable "zero ref" position, or

  // position the beam elsewhere

  // I would try leaving it out...

 }

}

Gotto go ... can not rip your sound apart just now!

Nor your grid...

Hehe...

Cheers

Malban

[Peer]

... also, when using inline assembly code in C, I strongly suggest using "asm volatile" instead of just "asm". Internal compiler optimization tries to rearrange code (C statements) as it sees fit whenver the order of statements is deemed to be without effect. So C statements "s1; s2; s3;" can be compiled as "s3; s2; s1;" if the compiler determines that reordering is without any side effects and thinks that the new order is better or results in faster assembly code. Inline assembly is a black box to the C compiler, so unless you are using compiler option -O0 (no compiler optimization at all), in general the inlined code block can be freely moved around and switched with the enclosing C statements. This can result in utter desaster, and such "bugs" are really hard to trace. "asm volatile" declares the inlined code block as volatile and thus creates a memory barrier, ensuring that the inlined assembly code is placed correctly between the enclosing C statements.

Cheers,

Peer