Jess Ragan
-
Posts
10,440 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Jess Ragan
-
-
It'd make more sense if you saw the ending in the arcade version. Just... trust me on this one.
-
2
-
-
Fixed the previously mentioned issues, and added some extra graphics for when Byron gets bonked. Oh, this is shaping up pretty darned well!
-
1
-
-
We have collision detection! And point labels! (You would not believe how annoyed I get when ColecoVision arcade ports don't have these.)
One slight problem: new Byrons will pop up in holes where there is already activity from bonked Byrons. This seems easy enough to fix, by placing a flag in the PoppinByrons routine preventing new Byrons from being spawned in those locations.
There's still no trace of sound or music. I have ideas for these, but as I've stated before this is not my strong suit.
-
1
-
-
On a related note, can you check for tiles near or colliding with a sprite? I presume VPEEK would be the way to go for this.
-
Dang! Good call! I just made the change and the game runs more consistently now. Can you explain why?
-
whackem_game.romwhackem_game.bas
The game! It's starting to resemble a game! I'm excited. So far I've got a working mallet, a working score (built from one 16-bit variable and one 8-bit variable; when both are full the score rolls over), a working timer, and one to three Byrons that pop out of holes when the timer "interval" reaches "intervalmax." There is still no collision detection; I'll need to squeeze that in there in a later update.
The game is probably way too fast at the moment, but I'm planning to include a dynamic difficulty adjustment based on the stage reached. The higher the stage, the faster the action and the more Byrons that appear. Butts will also appear more frequently in later stages, as well as deadly bombs that end the game instantly. As with your standard whack-a-mole style video games, the player is expected to reach a target score for that stage, which raises depending on the difficulty level.
Everything's running well so far, even if the code is an absolute mess. One sticking point is that swinging the mallet noticeably slows the game down, and spamming it will reduce the action to a crawl. I'm not sure if this can be fixed, but I certainly hope there's a solution.
-
1
-
-
More progress. I've got the mallet up on the screen... it's fully controllable with the joystick, and can be swung by pressing the fire button. (Probably either fire button, judging from the way the Coleco controller is read and how I've set it up. I don't know how to parse bits out of a byte, although I'm sure there's a way to do it.)
Next on the menu? Getting the Byrons to pop up!
-
We've reached a slight impasse, it seems. CONT1 can't be used to read diagonals, at least not by saying things like IF CONT1.LEFT AND CONT1.UP... for up and left. I can read the individual directions by addressing CONT1 directly, but this presents its own problems... pressing fire in conjunction with one of the directions adds 64 to the total, and could complicate matters slightly. I'll have to brainstorm and see what I can do to work around this.
-
It's said that the ColecoVision was made with "off the shelf" parts. Evidently the parts of the MSX and SG-1000 were taken from the same shelf, because the machines are so similar that they're dangerously close to compatible. The Dina 2-in-1 offers cross compatibility with the SG-1000 and the ColecoVision, and the MSX library is chock full of games originally released for the ColecoVision. The ColecoVision can even play music originally written for the Sega Master System, the next gen upgrade of the SG-1000!
So we know what these machines have in common. What's the difference between them? I know the MSX has a lot more RAM than the ColecoVision, but how do the SG-1000 and ColecoVision compare? Wikipedia offers scant information about the SG-1000, but for all I know the two systems could be one and the same, aside from a different BIOS and address calls. And what of the ZX Spectrum? How close is that to all of these "off the shelf" game consoles?
-
1
-
-
Golly. This is way better than the Parker Bros. version, and I was okay with the Parker Bros. version back in the 1980s. Moving up and down is a little tricky, but past that, it's hard to complain about what's here. It feels less like an abstraction of the arcade game and more like a legitimate port.
-
Now we're making tracks! I've got a playfield for the game, along with some limited animation. You can probably guess where I'm going with this... it's a Whack A Mole/Mole Attack style game, with Byron popping out from one of nine holes. A cartoon mallet is controlled by the player, and the fire button swings it. Bopping Byron on the head scores you points, while bopping him on the butt subtracts them. Reach the target score in the allotted span of time and you advance to the next stage; fail to do this and you lose. (Later stages have Byron holding up a bomb... this will instantly end the game if you strike it.) In addition to the standard whack a mole gameplay, I'm planning quick draw bonus rounds which challenge you to hit one safe target from several that pop up at once, or hit Byrons in the order that they appear (kind of like Simon).
It's still not playable, but I've got most (all?) of the graphics ready. I just need to figure out the game logic; I'm probably going to use a DIM statement to split the screen into nine sections, and each section operates independently from the others. Sound will likely be a problem... I've never been good at this, but it seems there are various tools that will make things easier for me, including one by the ever-busy Tursi.
byron_bash.bas byron_bash.rom byron_title.rom byron_title.bas
-
4
-
-
I've finally advanced to sprites on the ColecoVision, and noticed something peculiar. If you stack one sprite on top of another to add color and detail to it, it will flicker ever so slightly as the two sprites struggle for dominance. I thought it was because I was putting the sprite drawing commands inside an infinite loop, but no, even using the command once still resulted in flicker.
Evidently, you can't overlay sprites without the two of them fighting over which one displays, even if you're just using two sprites. It explains why when they drew Mario on Donkey Kong, they only had ALL red pixels, ALL blue pixels, and ALL white pixels in each of his three sprites, with none of the pixels from different colors touching.
-
Damn, Sly. I just saw your slideshow... you're swinging for the fences in a big way! Can you imagine how players in 1982 would have reacted to seeing this on a ColecoVision? A ColecoVision!
-
Okay, now we're humming along! (Keeping the source code private for this one.) I had a lot of fun building this title screen, but there's a lot of graphic data here, and I felt like I was starting to fly too close to the sun. When I used the latter VRAM addresses (220 and up), weird things happened, and all the color data was ignored for straight black and white images. Should that concern me? I thought I had the full range of those 256 characters.
I'm getting unreasonably excited about this, though. Even before the text has been added, this title screen kicks the asses of about 80% of ColecoVision title screens. Somehow "NINTENDO PRESENTS DONKEY KONG" in Space Invaders letters doesn't cut it for me. I was spoiled on the more elaborate title screens of NES games, and that's the feeling I hope to evoke here.
Also, I need to learn how to properly use the INCLUDE command. It'd be nice to address another program for data, rather than having it all dumped in the main code. It's more modular that way. I can come back and re-use that code for later games, should they happen.
-
3
-
-
(shrugs) Sure, here you go. Do note that I'm going to be stingier with my code when it starts resembling a game, though.
So, as a hypothetical. Can I define graphics in a title screen (preferably written as an external program), then re-define them for the content of a game later? A title screen could be more elaborate if I could dedicate all of the ColecoVision's VRAM to it.
-
1
-
-
Dang, there are like thirty different formats for some of these games. Some of these machines are very similar, true, but some are quite different. It must have taken years to make all these ports!
-
1
-
-
TMScolor is a real time saver, I'll tell you h'what.
So! I just made a thing. It's not a game, but there's animation, so that's a step in the right direction. The ROM should run in anything that can play ColecoVision games. (Also, phew. Even with TMScolor, this took some time.)
-
1
-
-
Hot damn! Super Game Module support, too? What's that going to give developers? 128K of RAM and the extra sound channels of the MSX?
-
2K? I can live with a margin like that.
I haven't learned how to use TMSColor yet. It might be a necessity for the more complex graphics I'd like to use in a project.
-
Okay, okay, I think I see the problem. Had to add one to the CHAR and COLOR DEFINE count.
Man, this is so nifty! Now I wanna do a whole bunch of stuff with the ColecoVision!
-
1
-
-
In the words of Archimedes, HELL YEAH.
I was weary of the font on the ColecoVision, but this adds a touch of class to it. Now I know how to create a custom font on this system, and so do you... just replace the bitmaps with whatever you please. The colors on the bottom can likewise be adjusted, but I chose a grey edge for the tops and bottoms of each letter, to give them a more metallic look. It's a thing Compile used to do on the MSX, as I recall.
(The Z is funky. I'm not sure why.)
Okay, so question. If I put this as an include in another BASIC program, it's not going to take up 12K of my total allotted space, is it? I presume it's just going to apply my custom graphics, terminate, and come back to the program itself with no significant loss in available storage. All that's just going straight to the VRAM, and it was already used by the BIOS in the first place.
-
1
-
-
Heh heh, "Wonder Hole."
-
Wait wait, there are 256 total 8x8 pixel characters, right? Are they part of the ASCII code? Could you technically just PRINT them on the screen with the appropriate ASCII code, as if they were text?
-
My understanding is that you can have eight sprites active at once, but the first four take priority. So if there's a lot of activity in one line, those four sprites will be drawn first, and the last four will be most subject to flicker. It seems most logical to assign the extra color to one of the last four sprites, because they'll be the most expendable.
I'm noticing that BASIC files can be nested with INCLUDE, resulting in less mess and a more modular design. If you, say, wanted to create a custom font, you could do that inside another BASIC file, and reference that file in your main program. If you wanted to use the custom font in several games, you could reference that file in whatever program that needs it, saving you time and keeping the main program tidy.
My question is this: is there an ASCII table specifically for the ColecoVision? What addresses would I need to use to change the system's font? I'm not crazy about the ColecoVision font; it makes every game look like Space Invaders, even when it's not Space Invaders.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Bebe's Kids
in Super Nintendo Entertainment System (SNES) / Super Famicom
Posted
It's legendary kusoge, among the worst games on the Super NES. As a result, it's frequently reviewed by YouTube content creators, particularly the yellers like AVGN. That notoriety probably explains its high market value. (Don't buy it, though! It's crap! It's like the Simpsons arcade game, if it had been made by the people who made Bart vs. The Space Mutants!)