Defender
Re: Defender
You are right! Time to make one....
The issue may be related to:
- number of sprites vs available RAM
- Defender effects such as fire (lines), explosions (particles) etc. vs Video Mode that can support it
Something to think about...
The issue may be related to:
- number of sprites vs available RAM
- Defender effects such as fire (lines), explosions (particles) etc. vs Video Mode that can support it
Something to think about...
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Defender
I think defender could be pretty well done in a video mode that was 2BPP and had 128 ram tiles and 128 rom tiles.
That should be able to be done at 256/288 pixels wide.
4 colours would be less than the arcade original 16 colours. 256 pixels wide less that arcades 320.
However there should be plenty of horses to do all the game play. I would think overall an easier ask than Tempest was.
That should be able to be done at 256/288 pixels wide.
4 colours would be less than the arcade original 16 colours. 256 pixels wide less that arcades 320.
However there should be plenty of horses to do all the game play. I would think overall an easier ask than Tempest was.
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: Defender
The Uzebox Space Invaders clone had the aliens as normal tiles (not sprites.) A trick, but maybe something like that would work for you. If you have SPIRAM and can move things back and forth maybe you can have the enemies as tiles and any animations as ramtiles.
Re: Defender
Mode 52! Since it can also have colour attributes, with some creative coding, it might be able to have more than 4 colours on the main game field.CunningFellow wrote: ↑Fri Jul 10, 2020 9:46 pmI think defender could be pretty well done in a video mode that was 2BPP and had 128 ram tiles and 128 rom tiles.
Otherwise the laser may be cheated by doing it with a few RAM tiles, with the compromise that it masks off backround for those 8x8 blocks where it appears. Due to the intensity of the action, this should be an okay trade-off, and this way the laser takes less CPU & less RAM to render.
Re: Defender
Whilst I'm sure this code is of little to no use for a UB port, I'm sure someone will find this disassembly of Defender interesting:
https://github.com/AaronBottegal/Defend ... ceCode.txt
https://github.com/AaronBottegal/Defend ... ceCode.txt
Re: Defender
I saw somewhere they used a disassembly of NES Super Mario Bros to create a perfect C replica using SDL. It might be possible to do the same for Defender and just modify the input, sound, and graphics bits. Definitely wouldn't be the fastest or most readable, but I would assume the most accurate.
Re: Defender
Me: Write a defender clone for the Uzebox
ChatGPT: Sure! Here is a simple Defender clone for the Uzebox written in C:
I can see it hasn't configured the controls, included all the required headers, created the tile data, you can't shoot and several other missing essentials before you would get something remotely resembling defender out of this but its interesting to see it it already has a rough idea what the source to a Uzebox game looks like and it's willing to have a go at writing at least the outline of a Uzebox game.
ChatGPT: Sure! Here is a simple Defender clone for the Uzebox written in C:
Code: Select all
#include <uzebox.h>
// player position and movement variables
int player_x = 64;
int player_y = 56;
int player_vx = 0;
int player_vy = 0;
// enemy position and movement variables
int enemy_x = 0;
int enemy_y = 0;
int enemy_vx = 1;
int enemy_vy = 1;
// game state variables
int score = 0;
bool game_over = false;
void game_loop() {
// clear screen
ClearVram();
// handle player movement
player_x += player_vx;
player_y += player_vy;
// handle enemy movement
enemy_x += enemy_vx;
enemy_y += enemy_vy;
// bounce enemy off edges of screen
if (enemy_x < 0 || enemy_x > 127) {
enemy_vx = -enemy_vx;
}
if (enemy_y < 0 || enemy_y > 63) {
enemy_vy = -enemy_vy;
}
// check for player-enemy collision
if (enemy_x == player_x && enemy_y == player_y) {
game_over = true;
}
// draw player and enemy
SetTile(player_x/8, player_y/8, 1);
SetTile(enemy_x/8, enemy_y/8, 2);
// draw score
Print(0, 0, "SCORE: ");
PrintInt(8*6, 0, score, 3);
// check for game over
if (game_over) {
WaitVsync(60);
Print(0, 2, "GAME OVER!");
WaitVsync(60);
while(1);
}
WaitVsync(60);
}
int main() {
// set up tiles and sprites
SetTileTable(tiles);
SetSpritesTileTable(sprites);
// set up player controls
SetPadCallback(0, &player_vx, &player_vy);
// main game loop
while(1) {
game_loop();
}
return 0;
}
Re: Defender
These would likely be more uzeful in writing a Defender clone than the ChatGPT pseudocode:
https://wordwarvi.sourceforge.net/ - Unusual as I think its the only game I've seen written in GTK except for the ones that come with GNOME / MATE but still, it's an open source Defender clone in C so it may contain some useful snippets?
https://github.com/historicalsource/defender | https://github.com/mwenge/defender - The original arcade game source code. Harder to read I'd expect.
https://wordwarvi.sourceforge.net/ - Unusual as I think its the only game I've seen written in GTK except for the ones that come with GNOME / MATE but still, it's an open source Defender clone in C so it may contain some useful snippets?
https://github.com/historicalsource/defender | https://github.com/mwenge/defender - The original arcade game source code. Harder to read I'd expect.
Re: Defender
Interesting, I had not seen that game before!
While I appreciate the ports that others do, I much prefer creating original Uzebox games. Unless they are physical puzzle games, those I enjoy "porting" to the Uzebox.
While I appreciate the ports that others do, I much prefer creating original Uzebox games. Unless they are physical puzzle games, those I enjoy "porting" to the Uzebox.