Vector Hyperdrive (A new Space Shooter)

[Opry99er]

Just a few lines of code.... My head's not on this planet right now...

 
100 CALL CLEAR :: CALL SCREEN(2)
110 CALL MAGNIFY(3)
120 CALL CHAR(96,"010101030206040C081A10171C101010808080C040602030105808E838080808")
130 CALL CHAR(100,"0000000000000201010200000000000000000000000040808040000000000000")
140 CALL SPRITE(#1,96,2,130,130)
150 FOR I=2 TO 16 :: SX=INT(RND*192)+1 :: SY=INT(RND*256)+1
160 CALL SPRITE(#I,100,2,SX,SY):: MOT=INT(RND*10)+3 :: CALL MOTION(#I,MOT,0)
170 NEXT I
180 FOR COL=2 TO 16 :: CALL COLOR(#COL,COL):: NEXT COL
190 CALL COLOR(#1,16)
200 GOTO 200

Edited August 16, 2015 by Opry99er

[+Vorticon]

The signs are all there: you've got the itch to code but not the time to do it. So this is a quick fix

[sometimes99er]

Just a few lines of code.... My head's not on this planet right now...

Very nice.

 

Save the planet !

 

The signs are all there: you've got the itch to code but not the time to do it. So this is a quick fix

Ha ha.

[Opry99er]

I am thinking of using the compiler for a vertical space shooter. I don't know how much time I will have to put into it right now, but with the High Score competition going on and such, I am fiending for space shooters for some reason.

[Opry99er]

Thinking a "wave" type game... Vertical Parsec (bosses... Dramites, Urbites, etc) increasing in speed each level... No refueling or anything... Just left to right movement, destroy the waves of ships for a high score. GORF meets Galaga in Lubbock TX?

Edited August 15, 2015 by Opry99er

[Opry99er]

Tonight I will add joystick motion, left and right for the player ship. Hopefully will get a few baddies designed using 'Patterns' and maybe get a few on the screen.

 

The stars will have to be fewer and farther between, as I will surely start hitting some flicker issues with the 15 that are currently onscreen... I am thinking 12 stars should be enough to maintain the 'feel'.

 

Player SPRITE will be #1, enemy SPRITEs will be #s 2,3, and 4, player torpedos will be #s 5 and 6, enemy torpedos will be #s 7, 8, and 9, stars will be 10-21.

 

Whew!!!

 

Hope it works out...

[ti99iuc]

i would want finished also the game that your son started with that great monster in the city !! :)

Edited August 15, 2015 by ti99iuc

[Opry99er]

Ahh yes...

 

Perhaps both could be compiled, put onto cart, and I could convince Jim to make a double-sided PCB for a double cart.

 

Useless these days, but novel.. Nonetheless.

[Opry99er]

Here's a little screen flash showing some of the graphics my son and I have been working on tonight.

 

There are 3 ship graphics (2 are mine, 1 is his) and there are 7 enemy graphics (4 are mine, 3 are his).

 

Using sometimes99er's "Patterns" program makes designing graphics fun and intuitive, and my 6 year old came up with some REALLY cool stuff!!!

 

Just run this. No joystick functionality yet, this is just a flip-screen of graphics for the different ships. The player ship will flip between the three we are considering, and the enemies will flip between the 7 we plan to use... They are not set in stone, just some ideas.

 

 

 

 
100 DIM EN$(7):: DIM SHP$(3)
110 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(3):: GOSUB 250
120 CALL CHAR(100,"0000000000000001010000000000000000000000000000808000000000000000")
130 FOR I=10 TO 21 :: SX=INT(RND*192)+1 :: SY=INT(RND*256)+1
140 CALL SPRITE(#I,100,2,SX,SY):: MOT=INT(RND*10)+3 :: CALL MOTION(#I,MOT,0)
150 NEXT I
160 COL=3 :: FOR STAR=10 TO 21 :: CALL COLOR(#STAR,COL):: COL=COL+1 :: NEXT STAR
170 XS=1 :: XE=1
180 CALL CHAR(96,SHP$(XS)):: CALL CHAR(104,EN$(XE))
190 CALL SPRITE(#1,96,2,165,130,#2,104,2,10,130)
200 CALL COLOR(#1,16,#2,
210 FOR I=1 TO 400 :: NEXT I :: XS=XS+1 :: XE=XE+1
220 IF XS>3 THEN XS=1
230 IF XE>7 THEN XE=1
240 CALL DELSPRITE(#1,#2):: GOTO 180
250 EN$(1)="01018386FCC062301C060101010000008080C1613F03460C3860808080000000"
260 EN$(2)="FFE2380D04457C42603E121311010100FF471CB020A23E42067C48C888808000"
270 EN$(3)="C0E0B098AFC07E02BEF11E030301010003070D19F5037E407D8F78C0C0808000"
280 EN$(4)="00F09FF13B0B3B1B0B0BFB7F39090D03000FF98FDCD0DCD8D0D0DFFE9C90B0C0"
290 EN$(5)="A412498CC46632127F6021311B0C06012548923123664C48FE06848CD8306080"
300 EN$(6)="E1BFC164388E027E1C86023E1C06030087FD83261C71407E3861407C3860C000"
310 EN$(7)="89309C06A2B2BFE066223311180C0603910C3960454DFD076644CC88183060C0"
320 SHP$(1)="010101030206040C081A10171C101010808080C040602030105808E838080808"
330 SHP$(2)="0101010302060C193A72E9C4FEC38183808080C0406030985C4E97237FC381C1"
340 SHP$(3)="0101031F12120B1F113171D3F212140F8080C0F84848D0F8888C8ECB4F4828F0"
350 RETURN

[+Vorticon]

Looking good

[Opry99er]

Thanks Walid.

 

Next is joystick control, then coincidence checking. I have a rough template I can use (which I wrote for 'Riding For the Brand') but it is a COINC(ALL) check, GOSUBbed out to individual checks... I will not be able to do a direct drop-in here due to the fact that the stars will be in coincidence frequently with other SPRITEs, so I will use a series of individual COINC checks...

 

This method would be too slow in standard XB for reliable collision detection, but using XB256 and the Compiler, I should be able to generate some solid gameplay with fairly accurate detection.

 

I have struggled with whether to allow "wraparound" for the player ship and enemy ships, and have decided to go with none allowed. I did not allow wrap in RFTB, and I liked the feel there, so I will use a similar design for Vector Hyperdrive.

[am1933]

Looks good, I like the main character sprites.

[Opry99er]

Thanks!!

 

Because I will be using XB256, there are 256 character patterns at my disposal, therefore the main player ship will have "banking" graphics as well... Move left, the ship will bank left, etc...

 

No idea how I will use up all these character patterns, but it will be fun trying!!!

[Opry99er]

Have fun.

 

 
100 DIM EN$(7):: DIM SHP$(3)
110 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(3):: GOSUB 390
120 CALL CHAR(100,"0000000000000001010000000000000000000000000000808000000000000000")
130 CALL CHAR(108,"0000000000000000000000000060600000000000000000000000000000060600")
140 FOR I=10 TO 21
150 SX=INT(RND*192)+1
160 SY=INT(RND*256)+1
170 CALL SPRITE(#I,100,2,SX,SY):: MOT=INT(RND*10)+3 :: CALL MOTION(#I,MOT,0)
180 NEXT I
190 COL=3 :: FOR STAR=10 TO 21 :: CALL COLOR(#STAR,COL):: COL=COL+1 :: NEXT STAR
200 CALL CHAR(96,SHP$(2)):: CALL CHAR(104,EN$(5))
210 CALL SPRITE(#1,96,2,165,130,#2,104,2,10,130)
220 CALL COLOR(#1,16,#2,
230 GOSUB 280
240 GOSUB 370
250 GOSUB 320
260 GOSUB 370
270 GOTO 230
280 CALL JOYST(1,X,Y)
290 CALL MOTION(#1,-Y+Y,X*6)
300 CALL POSITION(#1,Y,X)
310 RETURN
320 CALL KEY(1,K,S)
330 IF K<>18 THEN RETURN
340 CALL POSITION(#1,Y,X)
350 CALL SPRITE(#5,108,16,Y-10,X,-30,0)
360 RETURN
370 CALL POSITION(#5,BY,BX):: IF BY<20 THEN CALL DELSPRITE(#5)
380 RETURN
390 EN$(1)="01018386FCC062301C060101010000008080C1613F03460C3860808080000000"
400 EN$(2)="FFE2380D04457C42603E121311010100FF471CB020A23E42067C48C888808000"
410 EN$(3)="C0E0B098AFC07E02BEF11E030301010003070D19F5037E407D8F78C0C0808000"
420 EN$(4)="00F09FF13B0B3B1B0B0BFB7F39090D03000FF98FDCD0DCD8D0D0DFFE9C90B0C0"
430 EN$(5)="A412498CC46632127F6021311B0C06012548923123664C48FE06848CD8306080"
440 EN$(6)="E1BFC164388E027E1C86023E1C06030087FD83261C71407E3861407C3860C000"
450 EN$(7)="89309C06A2B2BFE066223311180C0603910C3960454DFD076644CC88183060C0"
460 SHP$(1)="010101030206040C081A10171C101010808080C040602030105808E838080808"
470 SHP$(2)="0101010302060C193A72E9C4FEC38183808080C0406030985C4E97237FC381C1"
480 SHP$(3)="0101031F12120B1F113171D3F212140F8080C0F84848D0F8888C8ECB4F4828F0"
490 RETURN

Still feels a bit "spongy" as it is not compiled yet, but I am just designing a framework at this point.

Edited August 17, 2015 by Opry99er

[Opry99er]

Tonight I will start by compiling what I currently have... I am hoping to achieve much higher responsiveness and less lag in control. With the gained speed, I SHOULD be able to allow 3 player torpedo sets to be in motion at once instead of 1. 1 is just not enough.

 

If I can work through the speed stuff, I intend on reworking the graphics into the additional character sets allowed by XB256 and creating some 'banking' graphics for the player ship.

[Opry99er]

Compiled, just as it was (with a couple necessary modifications to run with the compiler). MUCH more responsive.

 

I have also started working on multiple torpedos.... Have it working in XB, but for some reason (when compiled) it takes away my torpedo functionality altogether. I'll study and get back to you later.

 

Anyway, just drop this in DSK1 and run in XB as "VECTOR".

 

Use your joystick, fire with the fire button.

 

 

Enjoy

 

 

***EDIT***

 

My program here seems to be dumping some garbage into memory, as if you run it for more than 20-30 seconds, XB kicks out a "MEMORY FULL IN 10"...

 

I need to review my code and see if I'm doing something wrong.

 

Anyway, enjoy for 20-30 seconds anyway.

VECTOR.zip

Edited August 18, 2015 by Opry99er

[sometimes99er]

What hits me, when going through the code line-by-line, is the first time you hit line 370.

 

You're trying to get the position of a sprite that has not yet been created, - and then maybe deleting a sprite that has not been created.

 

And I think this may be happening over and over when running the program. This may be the course of "using memory".

 

XB may use memory too, as with the compiled version, but obviously at a much slower pace.

 

Edited August 18, 2015 by sometimes99er

[Opry99er]

Good thoughts... My multi-torpedo code is much worse, if that is the case.

 

I'll study and adjust as I can tonight... Hope to have a working multi-torpedo version in the next day or so.

[Opry99er]

I think I know what to do... I didn't think to do it because it adds several checks and variable allocations (which would bog down XB) but with the compiler, you would likely not even notice.

 

Add an "active" flag for each torpedo set which is set to "1" while the torpedo is in play and set to "0" when it is inactive.

 

IF TORP1 IS ACTIVE THEN TA1=1

 

Rather than checking the SPRITE's location to determine whether it is in play or not (which is likely causing junk to build up if there IS no SPRITE to CALL POSITION on) I will simply set and clear 3 separate flags on the fly...

 

This SHOULD fix my woes... Will report back later.

Edited August 18, 2015 by Opry99er

[Opry99er]

Crash bug fixed... also, you can fire multiple torpedoes.

 

 

Fire button detection is not perfect yet. I will optimize it and add some enemy animation in the next day or two.

 

 

Enjoy

VECTOR(8-18-15).zip

[sometimes99er]

Very smooth. Excellent.

[Opry99er]

Thanks sometimes!!

 

I have found several ways already to optimize my current TIdBiT source...

 

For instance, I am unconditionally branching to a torpedo "active" check 3 different times in the main game loop. The first line of each of the check subs is a status flag check to determine the status of the torpedoes.

 

Rather than doing that, I could check the flag in the main loop and branch ONLY if the flag is set to "1".

 

I think that will save me some cycles, making the "fire" button detection much more precise.

[Opry99er]

Tonight I will optimize the code snd hopefully get some collision detection done for torpedoes with the enemy ship.

 

Seems like a simple enough task.

[Opry99er]

Off work early... Code has been gone through, optimized, and the loop has been re-ordered to give priority to user-input/controls.

 

My screen parameter check is still virtually pixel perfect, and the fire button is arcade-sensitive.

 

Will try to get to collision detection and "score" tonight... If I do, I will post another demo for you to try out.

[Opry99er]

Got something working here, guys... I had a brain-shart on one line of code and it was fouling up the works... Check out the crap video capture with bad color here and enjoy!

 

 

http://www.youtube.com/watch?v=35JsRVYQgZ8&feature=youtu.be

VECTOR.zip