Jump to content

Photo

Restless II V0.6 - game in development

game xb flash assembler

76 replies to this topic

#26 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Sat Feb 7, 2015 2:33 AM

Hmm, gotta get back on track and do some work on this Restless II. Titles visited lately are, Snake II, War, Bomb, Get Through, Parallax, Thrust, Minecraft and Planet Patrol.

Here's the animation frames for the explosion:
 

restless.explosion.png



#27 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Tue Feb 10, 2015 2:42 AM

Here's the alien and the explosion when hit. Delays between frames will probably be tuned.

 

restless.alien.explode.gif



#28 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Tue Feb 10, 2015 6:12 AM

Here's the alien and the explosion when hit. Delays between frames will probably be tuned.

 

Looks very good. The delay looks fine for me, I kind off like the agitated impression that the alien gives off at this animation speed. The explosion is cool as well, at first I thought it might look better when played back a little bit slower but I think it's fine as-is. Just don't speed it up though :).



#29 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,465 posts
  • Location:Denmark

Posted Tue Feb 10, 2015 4:37 PM

It's incredible how many games, Munchman for instance, are ruining their animations by running them too fast when all it takes is a single shift instruction to fix it. 



#30 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Wed May 6, 2015 3:53 AM

So I've actually spent some time on this beast here and there. I’m afraid it only amounts to a few hours, but it’s looking good anyway.

All resources are loaded (font, colors, graphics, animations and sounds). And maybe about a quarter of the code has been written. We're at 39% of the 8K cartridge space.

The most interesting thing is how bad the sprite flickering will be, when the action gets hot in later levels.

Oh, and you'll get a trophy (on screen) if you make it to the end.
 

:)

 

 

 



#31 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,215 posts

Posted Wed May 6, 2015 5:10 AM

Nice progress report! I'm glad this one is still moving forward. :)



#32 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Tue May 19, 2015 2:51 AM

It's not that many hours I get to sit down and code. There's the usual diversion and distraction, - and then a few new number one priorities, including loosing my best friend ... But also, when you want to let you mind go, and escape whatever, then a bit of TI nostalgia, programming and game design is a relief.

 

I'm at about 54% of the 8K cartridge space, and low on Scratch-pad, but I think we'll be okay. The last update were missing the sprite patterns and that might have taken 5%.

 

I haven't really used indexed (and symbolic) addressing (EA page 59) versus register indirect (EA page 58). I'm thinking if one runs low on registers in a routine, that the first might be handy. But then it might also be a bit slower.

 

 

 



#33 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,021 posts
  • Location:Uzbekistan (no, really!)

Posted Tue May 19, 2015 5:27 AM

Keep on hacking! And sorry to hear of your recent loss.

 

best

 

Mark



#34 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Tue Jun 9, 2015 1:32 AM

I found in practice that the initial seed isn't always enough -- it's just a number that is steadily incremented on the master title page. Back in the day, I found that I hit a key so quickly and so predictably there that my number was frequently very close (if not the same - probably just close because back then I divided down). What helps with that, is I continue incrementing the seed on my own title page in any app I build, that helps improve the randomness.

 
I'm getting that too - to some extent.

I expect the built-in GPL startup to poll any key (violently) and get good seeds, but, or, - well, I'm hitting the same "series" of random numbers from time to time. Maybe not one startup after the other, but warm boot the game 10 times, and I'm sure to see the exact same pattern emerge (alien starting positions, directions and velocities). And that's what you get when you dive into a series a random numbers. Maybe I should keep the possible two seeds separate ? The result will be predictable too, but maybe I could go from 16 to 32 bit seed accuracy ?
 
01AC : RAND >FF Random number in >8378
01AE : SCAN
01AF : BR GROM@>01AC Wait for pressed key
 
At the splash screen, I think I will poll and secure that Enter is up while increasing the seed, then do the same the other way around (poll Enter for being hit). Much as suggested. The first part so that the Enter is not pressed when the GPL has finally cleared 15K (takes a relatively long time). Apparently doing so moving bytes from VDP to VDP.
 
034B : MOVE @>8300 TO VDP@>1000 FROM VDP@>0FFF Clear VDP
 
On the other hand, you're really not supposed to, or expected to, warm boot over and over, just to get the same pattern.

While I'm at it, I'll add a human distortion factor during game, - adding joystick state to the seed.
 
Also, I guess it's about time to have my old trusty random routine tested properly. It looks like 3 times 16 bits and the 8K ROM as a pool to try and mix things up, - whatever, "as is" it doesn't "beat" the initial seed >8378 (>83C0). 65,536 possible starting points !? 
 
:)

#35 RXB ONLINE  

RXB

    River Patroller

  • 2,798 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 9, 2015 4:05 AM

The RXB Source used this similar to XB code.

[1413] 6919 BF,80,C0        DST  >3567,@>83C0      Initialize random number generator

[1618] 6AAC 86,79           CLR  @TIMER             blink
[1619]               * RXB PATCH CODE FOR USER *****
[1620]               * G6AAE  SCAN                   Scan for a character
[1621]               *        RAND 99                Force randomize to be random
[1622] 6AAE 06,7C,B2 G6AAE  CALL DUSER             USER from EDIT mode
[1623] 6AB1 6A,CC           BS   READZ2            Found one!!!!

[3705] 7CB2 8E,A3,BB DUSER  CZ   V@CONFLG          RECALL FLAG?
[3706] 7CB5 7D,29           BS   NOUSER

[3745] 7D29 03 NOUSER SCAN

[3746] 7D2A 02,63 RAND 99

[3747] 7D2C 01 RTNC 

 

 

As you can see TI used RAND 99 

 

Not RAND >FF

 

Anyway hope it helps ....

 

Rich


Edited by RXB, Tue Jun 9, 2015 4:09 AM.


#36 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,386 posts
  • Location:Silver Run, Maryland

Posted Tue Jun 9, 2015 7:16 AM

The RXB Source used this similar to XB code.

[1413] 6919 BF,80,C0        DST  >3567,@>83C0      Initialize random number generator

[1618] 6AAC 86,79           CLR  @TIMER             blink
[1619]               * RXB PATCH CODE FOR USER *****
[1620]               * G6AAE  SCAN                   Scan for a character
[1621]               *        RAND 99                Force randomize to be random
[1622] 6AAE 06,7C,B2 G6AAE  CALL DUSER             USER from EDIT mode
[1623] 6AB1 6A,CC           BS   READZ2            Found one!!!!

[3705] 7CB2 8E,A3,BB DUSER  CZ   V@CONFLG          RECALL FLAG?
[3706] 7CB5 7D,29           BS   NOUSER

[3745] 7D29 03 NOUSER SCAN

[3746] 7D2A 02,63 RAND 99

[3747] 7D2C 01 RTNC 

 

 

As you can see TI used RAND 99 

 

Not RAND >FF

 

Anyway hope it helps ....

 

Rich

 

These are different cases.  sometimes99er is doing it for a single byte and wants to use the entire byte to allow for the largest possible, 1-byte number.  Your quoted XB code will call RAND 100 seven times, once for each of the seven Radix-100 digits for the largest possible XB floating-point integer, which can contain 14 radix-10 (decimal) digits.  Though probably obvious, the reason that the RAND call in XB is limited to 100 is that a radix-100 digit cannot exceed 99 decimal.

 

...lee



#37 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Tue Jun 9, 2015 1:27 PM

Thanks. Well, the boot provides a random seed at >8378 or >83C0. This is then being used in a game written in assembler.
 
:)
 
Just pondering about how to avoid running into the exact same attack patterns. - And I think it may very well be about my random routine and how I get a number into a certain range.
 

And I managed to get the same seed booting 14 times and quickly selecting the game. Seems as if >83C0 is in fact way better for a random seed !? There's even different numbers for try 1 and 14.
 

	>8378	>83C0
 
1	>FF30	>A57C
2	>FFD7	>5A94
3	>FF34	>9804
4	>FF33	>4E92
5	>FF3E	>CFA3
6	>FF2E	>1475
7	>FF2F	>9E27
8	>FF3A	>F8BD
9	>FF1B	>9CBC
10	>FF2A	>D0F3
11	>FF28	>0B55
12	>FF22	>A9CC
13	>FF27	>94E3
14	>FF30	>9A63


#38 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,386 posts
  • Location:Silver Run, Maryland

Posted Tue Jun 9, 2015 2:10 PM

 

Thanks. Well, the boot provides a random seed at >8378 or >83C0. This is then being used in a game written in assembler.
 
:)
 
Just pondering about how to avoid running into the exact same attack patterns. - And I think it may very well be about my random routine and how I get a number into a certain range.
 

And I managed to get the same seed booting 14 times and quickly selecting the game. Seems as if >83C0 is in fact way better for a random seed !? There's even different numbers for try 1 and 14.

...

 

The 16-bit value at >83C0 – >83C1 which is initialized at power-up and thereafter only gets updated by GPL’s RAND and other languages’ pseudo-random-number generators.

 

The byte at >8378 is not guaranteed to change.  It is used by the GPL RAND routine to store its result.  It is used by other routines as a flag.  The byte at >8379 is, of course, the VDP Interrupt Timer, so it changes every 1/60 second.  That is probably why your samplings of the full word at >8378 have the first byte unchanging.  You could try using the byte at >8379 twice to make up a full 16-bit word to see whether that gives enough variation.

 

...lee



#39 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Tue Jun 9, 2015 2:28 PM

The byte at >8378 is not guaranteed to change.  It is used by the GPL RAND routine to store its result.  It is used by other routines as a flag.

 

Oh yes, apparently. Looked good, as a word, and somewhat in sync with >83C0, - but then when the game cartridge is selected, the byte at >8378 seems to always be set to >FF. And it wasn't due to me being quick at selecting the game. Nice one. Thanks. 



#40 RXB ONLINE  

RXB

    River Patroller

  • 2,798 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 9, 2015 9:10 PM

 

Thanks. Well, the boot provides a random seed at >8378 or >83C0. This is then being used in a game written in assembler.
 
:)
 
Just pondering about how to avoid running into the exact same attack patterns. - And I think it may very well be about my random routine and how I get a number into a certain range.
 

And I managed to get the same seed booting 14 times and quickly selecting the game. Seems as if >83C0 is in fact way better for a random seed !? There's even different numbers for try 1 and 14.
 

	>8378	>83C0
 
1	>FF30	>A57C
2	>FFD7	>5A94
3	>FF34	>9804
4	>FF33	>4E92
5	>FF3E	>CFA3
6	>FF2E	>1475
7	>FF2F	>9E27
8	>FF3A	>F8BD
9	>FF1B	>9CBC
10	>FF2A	>D0F3
11	>FF28	>0B55
12	>FF22	>A9CC
13	>FF27	>94E3
14	>FF30	>9A63

Hmmmm this is why XB calls a RANDOM value from >8378 twice if you need a 16 bit number vs a 8 bit number.

 

Also as it is called twice this value will be much more random.

 

To make it even more random have it RANDOMLY  flip a coin on which byte is top and bottom.


Edited by RXB, Tue Jun 9, 2015 9:12 PM.


#41 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,822 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Jun 9, 2015 10:42 PM

A nice random number routine I got years ago and have used ever since is here. It has two nice features - one is that a seed that's off by even one with give you a very different sequence - which is good for the numbers we tend to have. The second is that it guarantees to produce every number from 1-65535 exactly once before repeating, in a pseudo random order (note that 0 is not included).

Another thing I like to do is instead of just incrementing the key, I'll often call the random function. I'm not sure if one is better than the other, offhand. ;)
 
*RND	RETURN RANDOM NUMBER IN R0 
RMASK
	DATA >B400		* mask for 16 bit random numbers
RND
	MOV  @RNDSED,R0         * Get seed
	SRL  R0,1		* shift down
	JNC  RAND01		* jump if 1 not shifted out
	XOR  @RMASK,R0		* XOR the top half
RAND01
	MOV  R0,@RNDSED         * Save this number for next time 
	B    *R11 
(edit: sorry, removed the 'inc @zmquad' - that was obviously part of the Zombie MOTIF game ;) )

Edited by Tursi, Wed Jun 10, 2015 10:13 AM.


#42 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Wed Jun 10, 2015 12:29 AM

<double> ?

Edited by sometimes99er, Wed Jun 10, 2015 12:30 AM.


#43 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Wed Jun 10, 2015 12:29 AM

Excellent.  :thumbsup:
 
Using >83c0 instead of >8378 solved the repeating pattern.
 
And the short and sweet random number generator above seems to work fine in the game. Adding joystick state or other tricks could potentially mess up the long repeat, so I won't do that.
 
I have reserved r9 for the seed, so it ends up like this,
 
;*********************************************************************************
; make a random number

rand
	srl  r9,1		; shift down
	jnc  rand1		; jump if 1 not shifted out
	xor  @rmask,r9		; xor the top half
rand1
	rt

rmask
	data >b400		* mask for 16 bit random numbers
 


#44 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,583 posts
  • Location:Germany

Posted Wed Jun 10, 2015 5:04 AM

The discussion reminds me of this: http://xkcd.com/221/



#45 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 517 posts
  • Location:Germany

Posted Wed Jun 10, 2015 10:36 AM

The discussion reminds me of this: http://xkcd.com/221/

 

 

Or this:  http://dilbert.com/strip/2001-10-25   ;)



#46 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Fri Jul 10, 2015 11:13 PM

Oops, been a month without any coding on this one (Restless II). Anyways, got a few ideas for moving forward.

Occasionally visiting other projects like Snake II, Destroyer, Planet Patrol, Mine Sweeper, Nonogram, a shooter, a few XB effect demos and other experimental stuff. Yesterday I spent a few hours on porting a relatively short tunnel raycaster but ran into too many obstacles (challenges) with speed being the biggest excuse for scrapping it.

:)

Edited by sometimes99er, Sat Jul 11, 2015 1:42 PM.


#47 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Thu Aug 27, 2015 12:54 PM

Version 0.1

Attached File  restless2c.bin   8KB   48 downloads
Attached File  restless2.rpk   2.86KB   31 downloads
Attached File  rest.ea3.obj   16.41KB   29 downloads Program name: REST
Attached File  rest.dsk   90KB   42 downloads File and program name: REST

 

Important note: Only demo - and not playable ! ;)

 

Instructions

The object of the game is to defend your spaceship, maneuvering it left and right as alien saucers dodge and dive in a relentless attack.

You get past the splash screen pressing Enter. Instantly, alien invaders begin to sweep about the screen. The invaders always keep moving in their current direction until they hit a screen boundary, then they rebound. Meanwhile, you move your ship left and right using the joystick to evade the erratic dives and swoops of the aliens.

Fortunately, you have your super plasma gun. Simply press the fire button on the joystick to unleash a bolt of this incredible power. The particle ray continues until it hits an alien, atomizing it, or until it reaches the top of the screen. If you hold down the fire button, the bolt continually repeats.

:)


Edited by sometimes99er, Mon Jan 11, 2016 3:06 AM.


#48 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Thu Aug 27, 2015 2:15 PM

Looks great, as usual. But in my test on js99er, only one out of three aliens moves around, and the particle ray doesn't collide with the aliens.



#49 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,822 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Aug 27, 2015 6:46 PM

Same results on Classic99 here with the C.BIN version. Looks great though! Nice use of character and sprite graphics.

#50 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • Topic Starter
  • 3,958 posts
  • Location:Denmark

Posted Thu Aug 27, 2015 10:46 PM

Yep, it's only version 0.1 and the instructions are more of an appetizer / setting the atmosphere. Sorry if I let you on to believe it was functional.

 

The number of aliens will increase with each level, starting out with 3 aliens. The aliens are hardware sprites. Ship, plasma and stars are software sprites (background graphics) - that's why I temporarily let "created by" be there (on screen).

 

Presently I've run low on ScratchPad and have at least two things I have to restructure.

 

;)


Edited by sometimes99er, Fri Aug 28, 2015 4:16 AM.






Also tagged with one or more of these keywords: game, xb, flash, assembler

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users