Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > C64 Productions > NEW GAME: GALAXYS
2002-09-15 15:12
Richard

Registered: Dec 2001
Posts: 621
NEW GAME: GALAXYS

I have produced a new retro-style C64 game called 'Galaxys'

You can download the game from this URL below:

http://www.redizajn.sk/tnd64/download_games.html

I await any reactions :)
 
... 30 posts hidden. Click here to view all posts....
 
2002-11-12 19:12
JCB
Account closed

Registered: Jun 2002
Posts: 241
Map scrolling is honestly not that hard to do. it's just a level of indirection from a message scroller plus basically repeating the same code for the whole screen.

I'm not sure how you code your message scrollers but if you do the "move screen contents left then add next letter from message to the end" way then you're halfway there. In it's simplest form it goes something like this. Just take each message "letter" as being a block number, say a 2x2 block, so shift it left 2 to multiply it by 4, that gives you your block offset. You also need to keep a toggling 0/1 value somewhere that you flip every 8 pixel scroll, add that to your offset and you have your current characters to print ,just put that in X then lda tiles,x store to screen then lda tiles+2,x and store that on the next line down.

Thats basically it for a horizontal tile map scroller. Like I say, it's the most basic way of doing it, you're limited to the number of tiles because of the multiply by 4 with no carry check, if you need more tiles just check the carry and alter the actual address of tiles on the lda tiles,x bit above, maybe use zeropage indirect addressing to save some time. Maps (or at least sections of them) can be pre-decoded to an area of ram to save time calculating the tile data offsets, you'd probably do this while the smooth scrolling was happening. You can also use 2 screens for a front/back buffer thing and decode the pre-scrolled map onto the back buffer while the smooth scroll is happening but this brings limitations of which direction are you going, if it's fixed then fine, if it's 8 (or even 2) directional then when do you decode the next directions map?, what if they change direction suddenly etc (look at Citadel and notice what happens when you move your ship, you don't have FULL control over it once you start moving) I think he uses the "window" method where the screen only scrolls when your ship reaches a certain point on the screen, that way he can almost always guarantee which direction he needs to scroll, the screen then scrolls a fixed amount in that direction, when you turn around he doesn't automatically neeed to start decoding in the other direction because you've got to move your ship to the other side of the "window" before it will scroll again..

If you want to try to code one and get stuck then I'm happy to help out, I can't remember if my email is on here but if it isn't you can get it from one of my lemon forum posts.
2002-11-12 20:28
cadaver

Registered: Feb 2002
Posts: 1160
Hmm...this pre-decoding sounds complex, and strange?! Maybe Walker just split the screen-copying on several frames and that explains the delay.

Anyway, I use startaddresses of blocks stored into a lookup table and bytes from the map are indexes to this table, this way deciding what to draw on the edge of screen is quite fast "on the fly", without any precalculation.

(in any kind of precalculation one's still shifting data around, I prefer to keep that to minimum as a LDA or STA is always a painful 4 cycles...)

And how I keep track of the map position is following: (for 4x4 blocks)
* variable "blockx" - indicates what char of block (0-3) is in the top-left corner of screen, in horizontal direction
* variable "blocky" - same in vertical dir.
* variable "mapx" - what block is in the top-left corner, measured from map's left edge (0-n)
* variable "mapy" - same for vertical, measured from map's bottom (0-m)

Things get fun when you have to account for sprite position changes due to scrolling. Simply put, this is achieved by converting the top-left screen position to pixels (multiplication) and subtracting that from all sprite coordinates before displaying

(here assuming that sprites positions are specified in "world" coordinate system - I never like to store them in "screen" coordinate system, too raw for me, although might be faster)
2002-11-12 20:29
cadaver

Registered: Feb 2002
Posts: 1160
Ah, of course not measured from "bottom", but "top"
2002-11-12 21:11
JCB
Account closed

Registered: Jun 2002
Posts: 241
Don't forget mine was supposed to be for Richard who doesn't understand how to do one, I can't go giving away all my secrets :P
2002-11-12 23:16
Rough
Account closed

Registered: Feb 2002
Posts: 1829
I disagree.

I believe Richard is the kinda person who wants to have the results quickly on the table and cant await until a good program "ripes" (does this word exist?) in its progress. that's why he also lets us constantly know about the progress of his programs cause he wants our attention on his work (which is an understandable and very human attitude, i know from myself) - if you, richard, would more concentrate on the work itself and make it your way than on the people's opinions about it during development you'd surely find the time and joy for a big project.

@jcb: you're not the only one. i also often wished to travel back into 1984 for and code something like 'wizball' 8)
2002-11-13 04:59
cadaver

Registered: Feb 2002
Posts: 1160
Yeah JCB, I merely wanted to provide a second, contrasting view to the thing...

2002-11-13 11:24
cadaver

Registered: Feb 2002
Posts: 1160
rOuGh, your arguments are also valid, but I'd like to suggest 2 tests/questions to determine whether Rich is actually up to writing more complex games:

1) Programming a music replayroutine? Not necessarily anything to rival DMC- or JCH-playroutines, but something that can handle note pitch, their duration, and instrument parameters (ADSR, wave etc.)

2) Programming a fully functional Tetris clone?

These tasks may seem trivial but both involve data structures and logic that's more complicated than any of his games up to date.
2002-11-13 12:28
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Erm, *i've* never coded a music driver or Tetris clone...?!
2002-11-13 13:17
Pater Pi
Account closed

Registered: Jan 2002
Posts: 121
You aren't Richard.
You are The Magic Roundabout!
2002-11-13 15:19
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
Ah, i'm glad we've cleared that up... i think?
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Rebok/BOOM!/Tropyx
Luke/The Obsessed Ma..
Higgie/Kraze/Slackers
Elder0010/G★P
wacek/arise
Magic/Nah-Kolor
rime/Fancy Rats
grip
chriz74
Guests online: 122
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.038 sec.