You need 2 joypads for this as I don't have a computer controlled player yet. I'm looking for some people with 2 joypads and a friend to test this out.
Try It Now!
- Asterduel1.jpg (118.27 KiB) Viewed 152 times
Asterduel - A two player split screen space battler
Forum rules
This is the only download category to upload works in progress of your application or game.
This is the only download category to upload works in progress of your application or game.
Asterduel - A two player split screen space battler
Battle in space against a friend in this two player space battler. The split screen gives each player has their own view of the battlefield (I believe this is a 1st on the X16?). Destroy asteroids and collect the energy crystals inside. Return to your base to launch lasers at the other player's shield and base.
You need 2 joypads for this as I don't have a computer controlled player yet. I'm looking for some people with 2 joypads and a friend to test this out.
Try It Now!
You need 2 joypads for this as I don't have a computer controlled player yet. I'm looking for some people with 2 joypads and a friend to test this out.
Try It Now!
- Attachments
-
aduel.zip- (103.77 KiB) Downloaded 26 times
Re: Asterduel - A two player split screen space battler
Very cool! Yea might be be first with this concept, I like it!
Obviously I am not 2 players. Maybe make a video when two are playing?
A visual improvement suggestion: I am assuming your HUDs are 16 pixels high, and a visible playfield is 224 pixels high, and sprites are 32x32 max? If that is the case, then you have an opportunity to automatically clip the vertically wrapping sprites since the combined height of top HUD and bottom HUD and playfield equals 256, and the bottom playfield has a similar situation if you imagine the bottom of the screen being the start of another HUD (like a top for a playfield 3 that doesn't exist).
Because the second playfield starts at 256, all those sprites can just keep the high byte of the Y offset 1, and the low byte can automatically wrap between 0-255.
If a sprite is at Y position 255, one pixel of the top of the sprite will be visible (assuming all sprites are 32 pixels high) over the bottom HUD, and when adding 1 will wrap back to 0, which makes the sprite completely hidden under the HUD, but add 1 again and the bottom pixel of the sprite will be visible under the top HUD. Since sprites are always in motion, that single pixel position of being hidden shouldn't affect gameplay, and it will look more smooth since you don't see sprites "teleporting". Hopefully this makes sense.
Obviously I am not 2 players. Maybe make a video when two are playing?
A visual improvement suggestion: I am assuming your HUDs are 16 pixels high, and a visible playfield is 224 pixels high, and sprites are 32x32 max? If that is the case, then you have an opportunity to automatically clip the vertically wrapping sprites since the combined height of top HUD and bottom HUD and playfield equals 256, and the bottom playfield has a similar situation if you imagine the bottom of the screen being the start of another HUD (like a top for a playfield 3 that doesn't exist).
Because the second playfield starts at 256, all those sprites can just keep the high byte of the Y offset 1, and the low byte can automatically wrap between 0-255.
If a sprite is at Y position 255, one pixel of the top of the sprite will be visible (assuming all sprites are 32 pixels high) over the bottom HUD, and when adding 1 will wrap back to 0, which makes the sprite completely hidden under the HUD, but add 1 again and the bottom pixel of the sprite will be visible under the top HUD. Since sprites are always in motion, that single pixel position of being hidden shouldn't affect gameplay, and it will look more smooth since you don't see sprites "teleporting". Hopefully this makes sense.