EricBall
-
Posts
2,427 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Blog Comments posted by EricBall
-
-
Although I'm not a regular concert go-er, I know what you mean. I want to slap the guy on the mixing boards, take down the main volume a couple of notches, then rebalance the sound so I can actually hear the lead singer.
But it sounds like in this case the guys on stage weren't helping their cause any either. I mean, I can understand a guitar feedback solo at the Sister's of Mercy concert I went to at University as a replacement for the orchestral chorus, but this sounds like the band was trying to make up for not knowing the songs.
-
As much as I'm enjoying your retrospective, please don't feel you have to be an obsessive-compulsive completist about it. Family, particularly kids, is very important (along with providing necessary food, clothing & shelter). Sometimes there just aren't enough hours in the day to get everything done, and IMHO playing videogames should be at the bottom of the to-do list (ahead of reality TV, at least).
-
1
-
-
The Supercharger is compatible with most 7800s, but only in 2600 compatibility mode. The 7800 BIOS will detect the Supercharger BIOS as a 2600 cart (which it is) and lock the 7800 into 2600 mode, turning off the 7800 MARIA GPU.
However, there's nothing that says a 7800 version of Batari Basic couldn't be created. Of course, since the 7800 MARIA GPU is nothing like the 2600 TIA everything associated with the 2600 kernel will need to be replaced with a 7800 equivalent. The basic data & control stuff should be portable though.
The 7800 also has a full 32K ROM address space and 4K of RAM, so it really doesn't need the SuperCharger's 6K of RAM/ROM.
-
Supercat - hmm, I hadn't given any thought yet to enemy-enemy collision detection. I probably should simply to prevent / reduce overlaps.
My current frame loop goes something like this:
- every frame update the movement logic for only one sprite (player or one enemy). 5 sprites (player + 4 enemies) for PAL, 6 sprites (player + 4 enemies + 1 unused) for NTSC
- player sprite moves 1 pixel on movement logic frame, grid square is 4 pixels width, 8 pixels high
- falling sprites (player & enemy) move 1 pixel twice every sequence (so you fall twice as fast as climbing down)
- enemy sprites move 34.1333/256 pixels per frame
So I've already got a current sprite; everything is "out of phase". Of course, there's no code yet so things might change.
-
Skeleton & Skeleton+ were released as separate NTSC and PAL versions. In addition to correcting for the different frame rates, you also need to consider how you will handle the extra vertical resolution. Stretching stuff by 20% ain't always possible (The PAL Skeleton has an extra rib!) and it can increase the size of any stored bitmaps. (Which really made PAL Skeleton/Skeleton+ a tight fit in 4K.) Also don't forget to adjust any vertical velocity vectors!
-
Nope, constant cycles not required. Thanks for the optimization, I just wasn't thinking this morning.
-
lda xposf,x
cmp #36 ; clears carry bit if a < 36
sbc #34
sta xposf,x
lda xpos,x
sbc #0
sta xpos,x
Spreadsheets are wonderful what-if tools.
-
I'd leave out "Screen Resolution; Base resolution is 160 x 192", because it's very misleading. In fact, I'd focus on the line-based aspect of 2600 graphics. e.g.
Each line of the active screen is made up of the following objects:
background colour
40 pixels of playfield
two 8 bit player sprites
two 1 bit missiles (same colour as the players)
one 1 bit ball (same colour as playfield)
You've gone into a fair bit of detail about player sprites, i.e. width & duplication, which probably aren't appropriate to the non-programmer. If you're simply trying to give them a flavor of what the 2600 is capable of, I'd leave out anything (other than playfield) which would require a precise mid-line updates.
You might want to mention the 48 bit player sprite possibility, although that basically uses the entire line. (No playfield updates.)
Oh, and that 192 lines per screen (NTSC) is just a recommended value. The active screen can easily be 200 lines or more, though you risk having some of the graphics offscreen.
-
What I've done in the past is to put it in a simple spreadsheet which then makes it easier to shift sections of code around.
-
Manuel, you are, unfortunately, correct; now that I think of it. Just a slightly different way of doing what has been done before. Not even necessarily any better. And you're right that equates would make it more readable. Maybe something to consider for Rev 3 when I have more time.
Glenn, it's always been my intention to have Leprechaun multi-load. Basically each level would be 1K of data containing the background bitmap and other level data. The rest of the code would remain the same, including some kind of level select screen. However, I'm not to that point yet. My primary focus is on getting the player & enemy movement logic down.
Chirs, tracker in the most simplistic sense of playing a sound track, versus the various MOD-style trackers which could play samples back at various rates to mimic instruments. Unfortunately, the VCS doesn't have the horsepower to do this without a Pitfall2 style coprocessor.
-
I wonder if QBASIC is still hidden on the Windows XP CD somewhere. I still use it for a variety of different things and on modern PCs it's amazingly fast.
I also cut my programming teeth on BASIC, starting with AppleSoft on the Apple ][+. My first ASM was 6809 on the CoCo; and when I tried to later learn 6502 I couldn't understand how to live without a 16 bit index register and dropped it until I got into 2600 programming.
Oh, and you're right batari. Indexed indirect is almost completely useless. I can't imagine many cases where it would be worth the ZP space to store an array of address pointers to single bytes. Better to store the array in main memory, copy the address pointer to ZP using ABS,X then access it with (ZP),Y. At least then your pointers can be to multi-byte objects.
-
Ahh, good to see that someone else has taken up Glenn's challenge. And I wouldn't mind at all losing to PoP 2600; I recall playing the PC version fondly. (Well, some of the traps/puzzles were a little annoying.) I wish you the best of luck, you've taken on a very challenging task.
My only advice is to play through the PC version and make careful notes about everything. When I started thinking about Leprechaun (then known as Gold Digger) I made the explicit decision not to try to duplicate Lode Runner simply so I wouldn't have to worry about trying to recreate the gameplay exactly. You may find yourself making the same decision, although it appears you are doing a fine job of adapting the look of PoP.
I also wouldn't worry too much about performing collision detection in software. Although hardware collision detection takes away the comparison requirements, it puts a lot of strain on making the graphics work right. Since you are using the ball for the sword, you could try to use the ball<->player HW collision detection, but I think you would find it very difficult to avoid false hits and misses.
-
Thanks for the explanation - by MSB you mean most significant *bit*, right? I was thinking "byte" and it wasn't making any sense to me.
The tracker is very cool. Am I reading the code right; it uses 8 bytes of RAM for the single channel?
MSB is bit (in this case), maybe I should use msb :-)
8 bytes for 2 multiplexed channels. I only use 1 channel in my demo, but if I wanted to have a bass line, I'd just use the following code:
ldx #0
dec notedel,x
bne 1$
jsr nextnote
1$ inx
dec notedel,x
bne WAITIM
jsr nextnote
-
Three comments:
One: This seems really cool!
Two: I don't understand this:
Song (words): <$8000 $8000 OR word is pointer to next song entry >$7FFF word is pointer to next sequence
Three: Is there supposed to be a binary attached to this or am I missing something important?
Three - whoops, I've added the attachment.
Two - a song is a list of pointers to sequences, but for flexibility it can also contain a pointer to a song. If the MSB of the pointer is set, then it's a sequence pointer. If the MSB is clear, then the MSB is set and used as a pointer to the next song.
See the sample code.
-
I'd be interested in knowing you you translate player position to playfield bitmap position for things like chopping through the floor.
I'm working on this chunk of code right now. But here's a preview:
; get grid data for position X (A register), Y (Y register)
GETGRID
LSR
LSR ; assume on grid, implicit CLC
TAX
LDA XBANK,X
STA PTR+1
LDA #$08
STA PTR
LDA XFBIT,X
TAX
LDA #$80
STA GGOUT
GGLOOP
TXA
AND (PTR),Y
BEQ GGSKIP
SEC
GGSKIP
ROR
INY
BCC GGLOOP
RTS
-
Found the last code mentioned on my website. But I have a later revision to one of the files. I've made a printout of the merged diff; trying to make sense of it all.
-
Would you believe that my first challenge is finding the most recent source code? Teach me to have too many development environments / code repositories. Toss in some drive failures, and backups on unlabeled floppied. Ugh.
-
I've also now started a female DS Scout/Counselor with the express purpose of:
1. Unlocking HK-47
2. Doing the DS thing at every turn, to see those branch choice results
3. Seducing Carth
I'm right now playing her solo, but I pull in the rest of the party when I want. (e.g. to bump off Selven).
I'm going to try to play both the LS and DS in parallel; I'll see how long that lasts.
-
Started a new game as a DS Scoundrel, but kept getting my butt kicked. Then discovered I needed a Scout/Sentiel with high INT to have any chance of building up the 17 repair skill required to completely unlock HK-47. Uhh, no.
So, now I've started over (again...) with a Male LS Soldier (now level 5). I've started with STR=16, WIS=16, INT=8, 12 for the rest. Not a lot of of VPs which hurts in many on one battles, but a good starting point.
-
To summarize: blank is hcount 0-79, sync is 32-63 and net is 256
So, if we say that end of blank (hcount=80) is pixel #0, then the net is at pixel #176, and the end of the active screen is pixel #375 (hcount=455). So the net is shifted slightly to the left (pixel #176 vs pixel #188) than the center of the active screen. Not a really big deal, and probably tweakable with the CRT trim pots. And since everything else (paddles & ball(s)) will be relative to the net (which is nicely at hcount=256), the difference is immaterial.
-
No, HSYNC causes the horizontal retrace. HBLANK just turns off the electron beam so nothing gets drawn beyond the edge of the screen. Not important for Pong, but useful for other games where sprites wrap around.
As for your second question... hmm, how to explain this. Basically as the electron beam is going across the screen it is also going down slightly; enough so that after a full line interval it's on the next line. The horizontal sync causes the beam to quickly return to the left side of the screen. So the electron beam zig-zags down the screen.
-
Not that I'm a teacher, but might I offer the following suggestions:
1. Make sure you have proper backing at the meeting, i.e. principal or union rep.
2. Pull as much documentation together as you can find. i.e. show work that was handed in late or where you made it easier to achieve better marks.
3. Make sure the parent understands what you have done and attempted to do for their child. (Who know what little Johnny has been telling them.)
4. And for the future, make sure you know what the expectations are for IEP and have your side documented.
-
Don't worry about it. I've done equally dumb things. The trick is to find them before Al starts selling carts.
-
I didn’t realize that you already published a playable demo but now I found one in the forum.
A really good conversion!
http://ericball.atariage.com/spacewar.html will always have the most recent released version.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Ooze Lives!
in potatohead's Blog
A blog by potatohead in General
Posted
In my (limitted) experience 2600 kernels don't have to be time sinks. IIRC for Skeleton I spent a bunch of time trying to figure out how to convert the maze to something a 2600 kernel could display. Then there was some time getting the actual kernel working, i.e. figuring out the timing constraints. Later, I spent time doing some space optimization and squeezing in additional features.
For Leprechaun, again I had to spend some time figuring out how to store the level & player data in RAM/ROM so the kernel could efficiently use it. That then leads to actually creating the kernel. Again, I might try to add some optimizations or features, but this one is fairly tight already.
But in both cases the kernel is less than half of the story. Coding the rest of the gameplay code for Leprechaun is taking easily several times what the kernel did.
Now, for some games kernel related coding may take more time, especially if you are continually adding more features, changing the kernel data structures or optimizing. But I still don't think it's going to take 50% of the time.
Now the 7800 doesn't have a display kernel like the 2600, the MARIA GPU handles that part. (Well, there are uses for a psuedo kernel, like reading paddles, but they aren't as complex as a 2600 kernel.) But instead, you have a display list creation kernel, which takes the game data structures and creates the display lists which the MARIA GPU parses into the actual display. But this 7800 kernel doesn't have the timing constraints that a 2600 kernel lives & dies by. No chasing the raster here. So, again, most of the coding time is spent on gameplay logic.