Jump to content
in8regs

Game port prospect: Acorn Electron's Gunsmoke.

Recommended Posts

Posted (edited)

Here is GUNSMOKE running normally, followed by GUNSMOKE running in Extended BASIC but loading the screen, colors, and character definitions using compressed DATA statements.

The original XB program uses 10899 bytes of memory; the XB program using compressed DATA statements needs just 2152 bytes of memory.

Note that the original program is running in CPU overdrive, while the compressed version is running at normal XB speed.

N.B. This is not compiled!

 

(Edit) - I omitted CALL SCREEN(1), so the border is not black on the compressed version.

 

GUNSMOKE.gif

 

Edited by senior_falcon
  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites

I got the same problem of course and old under the word SHERIFF there were some other missing chars but running the expoert with Exclude Blank Chars and and in the Options I set Super Charater set evething was fine...

Finaly I got the right game screen...

Please find enclose the export (size: 12665) 

 

Little question : for the sprites definition no way to get the code ans for the map ? I copied manually each definition of the 16x16 ...

with XB256 I need to define the sprites as in XB but using CALL LINK("CHAR2",x,y) ? 

gunsmoke_sprites_XB256_orig1.xb

Share this post


Link to post
Share on other sites
Posted (edited)

Little question : for the sprites definition no way to get the code ans for the map ? I copied manually each definition of the 16x16 ...

with XB256 I need to define the sprites as in XB but using CALL LINK("CHAR2",x,y) ? 

 

With XB256 sprites are created exactly the same as when using standard XB. CALL CHAR is used to define the pattern of a sprite. You can use characters from 32 to 143.

CALL LINK("CHAR2") is to define the characters in screen2, not the sprites.

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

uhmmm .... I'm a little bit confused ... you mean that I could define the pattern for characters from 32 to 143 with CALL CHAR and use them for the sprite and at same time define the same set of characters 32 to 143 with CALL LINK("CHAR2") with no overlaping issue ? obviously in XB256 and SCRN2 "mode"

Share this post


Link to post
Share on other sites
1 hour ago, whoami999ster said:

uhmmm .... I'm a little bit confused ... you mean that I could define the pattern for characters from 32 to 143 with CALL CHAR and use them for the sprite and at same time define the same set of characters 32 to 143 with CALL LINK("CHAR2") with no overlaping issue ? obviously in XB256 and SCRN2 "mode"

It's correct. With XB256 you can use 256 chars (0 to 255) in screen2 and the standard XB set (32-143) for sprites. No overlap. There are also some other interesting functions and XB256 code can be compiled. All the information are on the manual, just search it on this AA forum.

 

  • Like 2

Share this post


Link to post
Share on other sites

Here we are... I did some test and it seems that with the compiled version I get issue ... I checked the reserved name for SUB for variable in XB256, try to make the correct steps for the compiling.. but despite this I get two different result with the XB256 version of GSTEST XB256 pgm. and the same pgm but compiled .... see AVI attached ... enclose also the source code maybe some one could keep an eye and provide suggestions for prformance improvement ... 

(I already considered the definitio for the all sprite left and right and using CALL PATTERN but I would lke to see the result with the compiled version before may is enough fast to manage the reload of the patterns in the same char set)...

All recommendation are welcome...

 

PS: parameters 

DELAY = delay with CALL PATTERN for the run sequence of the sprites

YVEL = CALL MOTION displacement for the sprites

COORD X and Y = initial X,Y coodinate of the sprite

DELSPRITE = sprite deletion before pattern reload for sprites left side / rightside   1=Sprite delete ative  

COLOR = Sprite color

CALL LOAD =   CALL LINK("SYNC",xx)    1=activate che Sync

TIME= xx in the CALL LINK("SYNC",xx)        1/TIME Sec

gunsmoke XB256_test_sprite - Copy.txt

Share this post


Link to post
Share on other sites

S=Left D=Righ  L=Shot (don't work)     X=Exit

if you press 1 or 2 or 3 or 4 or 5 the position of the corresponding sprite is displayed 

 

there are a couple of SUB usefull for debug/tracing the pgm 

XDEBUG = prints 5 variable 

XWAIT(0) = stop pgm execution 

 

Share this post


Link to post
Share on other sites

This is strange. Sprites have been working for many years and should be thoroughly debugged. I will take a look tonight. It must be something simple.

Share this post


Link to post
Share on other sites

I simplified the code from the SUBs unused ... should be easier to read ... I'm agree with you that probably it will be a stupid detail ... but it's my very first experience with XB256 and compiled version so please excuse me :)

thanks for your patient and time ... but XB256 added to compiled version velocity it's an letal cocktail.... 

I'm ready with the background and the ideally with the movement of the heros... I've already some idea for the enemy ... but soundtrack will be very hard for me ... I kindly ask you support with this or suggestion ... or even a pre-made soundtrack if available ... and the sound of the shot ... :)

 

Thanks and Ciao

 

 

gunsmoke XB256_test_sprite_V2 - Copy.txt

  • Like 2

Share this post


Link to post
Share on other sites

After pasting your two programs into Classic99, neither one would run successfully for me.

One of the problems is that you have commented some of the lines incorrectly. e.g.:

1151 DATA 96,0000000000000000000003FFFFFFFCC0000000000000030C30F0F0C0C0000000 PISTOLA 1

Another thing I noticed is the use of the double colon statement separator at the end of lines. e.g.:

1803 DISPLAY AT(12,3):"G  A  M  E    O  V  E  R"::

XB tolerates this, but it crashes the compiler.

Here is another problem:

1730 CALL LINK("DELAY",5) :: DISPLAY ERASE ALL

From the manual: "An XB trick to save memory is to use DISPLAY ERASE ALL to clear the screen. This crashes the compiler
which expects DISPLAY to actually display something. Use CALL CLEAR if you just want to clear the screen."

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites

I looked a little harder at this tonight. I made the changes noted above:

1 - fixed the comments at the end of the data statement.

2 - changed the DISPLAY ERASE ALL to CALL CLEAR

3 - removed 3 double colons at the end of the line

It now runs fine in XB, and when compiled it seems to run fine as well. Your problem was probably the double colons at the end of the lines.

GUNSPRITE.gif

  • Like 2

Share this post


Link to post
Share on other sites

I see that gap in character when it moves is that Classic99 not having a fast enough memory or processor?

It does the same thing in RXB or XB so I just assumed it was Classic99 was not empowered with fast enough PC memory and processor?

Share this post


Link to post
Share on other sites
1 hour ago, RXB said:

I see that gap in character when it moves is that Classic99 not having a fast enough memory or processor?

It does the same thing in RXB or XB so I just assumed it was Classic99 was not empowered with fast enough PC memory and processor?

Classic99 fairly accurately mimics the behavior of a real TI99 and as we all know, the TI99 doesn't have a fast processor or memory.

I haven't looked very hard at the program, but the gunfighter is pretty big so he must be made up of several sprites. I'm guessing that one sprite is moved, exposing the gap before XB catches up and moves the next sprite. It would probably be better to move the sprites in the opposite order so the gap is not exposed.

  • Like 2

Share this post


Link to post
Share on other sites

HI Falcon ... finally  I decided to review completely the approach and the code ...  guess that using CALL MOTION was basically the problem above al in terms of graphical result of the movement...

So I simply considered the high speed of the compiled version and using a simple CALL SPRITE... Compared the original version (let's say that I consider the original version the one in the  2nd video in the 1st pge of this thread) and the result is quite similar ... I'm really happy with the result ...just playing with the run parameters I count to obtain the good balance with the sprite movements ... Sofinally  I by-passed the issue and show must go on ... now I'm preparing the AI of the game that despite is very simple for me it's an hard task since as I said it's my first experience...

Anyway here you can find the video of the speed test .. I count to create and test the compiled version and test it tomorrow...

Please when will be the moment I Kindly ask you assistance with sound effect and sound track ... (please)

Thanks a lot for your time and commitment 

  

 

Share this post


Link to post
Share on other sites

I just compiled the same version of the program and when try to shot in addition to sprite #8 that is the bullet also sprites #1 and #2 run away ... only a new movement left or right compact again the sprites....

I don't understand .. It's really a pity .. I'm stand still again ... 

what's your opinion  ... attached the video and the program source

GSV10.txt

  • Haha 1

Share this post


Link to post
Share on other sites

i cannot view your .AVI videos. After removing the comments from some of your DATA lines I was able to get the program running in XB256. (I have no idea how you are able to run what you post!)

It compiles fine. I can use S and D to move right and left. J raises the hand with the gun. I don't know any of the other controls for this demo.

Share this post


Link to post
Share on other sites
10 minutes ago, senior_falcon said:

i cannot view your .AVI videos.

Hey, @whoami999ster, if you are running Windows, see about getting a Windows build of ffmpeg, then process your AVIs with this command:

 

ffmpeg -hide_banner -bitexact -i classic99.avi -c:v libx264 -pix_fmt yuv420p -movflags faststart classic99.mp4

 

The -bitexact option will make sure there is little difference between the pixelation of the input file and the resulting output.  Replace the "classic99.avi" and "classic99.mp4" with appropriate filenames.  The resulting MP4 file should play in the AtariAge player, which takes advantage of the HTML5 media player when appropriate.)  This is how I processed your videos earlier.

  • Like 2

Share this post


Link to post
Share on other sites

Ha ha, he's shooting off his own head. You can run the AVIs in the open source VLC media player.

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
6 hours ago, Asmusr said:

 You can run the AVIs in the open source VLC media player.

That was the second thing I tried, but it doesn't work on my computer either. I think it's time to update my system.

 

What I really need to know is how the controls work.

Edited by senior_falcon

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, senior_falcon said:

That was the second thing I tried, but it doesn't work on my computer either. I think it's time to update my system.

 

What I really need to know is how the controls work.

You may need to install an up to date codex package. Several out there, just get one from a reputable site.

Edited by RickyDean
ai spelling

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...