Lodmot

Alright, so I'm still working on that ball-paddle game for my college class, and now I've run into a new problem.... xDDD I'm trying to make it so that when the ball hits the block, depending on which side the ball hits the block on, it reverses either its horizontal direction or vertical direction. For example, say this is a playfield pixel and the ball collides into it from the left: ----> * [] The ball should reverse direction horizontally: * <---- [] Also, if the ball comes from the right, it should do the opposite. The same should apply for vertical collisions as well, so if the ball comes down and hits the playfield block from the top: | | | v * [] It should reverse direction and start moving upwards: * ^ | | | [] I know that in order to get the collision between sprites and individual playfield blocks, I have to do the conversion formulas from playfield coordinates to regular sprite coordinates, which I did. But I'm having trouble figuring out how to make the ball tell which side of the individual block it's hitting, so it could bounce off going the appropriate reversal direction. Any ideas? xDD Quadraball_Build1000.bas Quadraball_Build1000.bas.bin

Well, I wanted to do a project that was unlike anything the rest of my class was doing. Everyone else is doing like a magazine or a video or something. And I wanted to showcase something different. Doing an Atari game for this project also represents what I want to do in life, to make games that are fun. And it also demonstrates everything I've learned up to this point about game design. So yeah. o3o I feel it's a nice final project before I get my associates'

A very sensible post. I'm going to be presenting this game on my actual console at the end of the semester to my entire class, so I'm gonna want a functional game that everyone can just pick up and play. In case it's relevant at all, the final due date is going to be May 1st at the earliest. We're supposed to do an Alpha test AND a beta test, regardless of what we chose to do for our Digital Arts project.

I looked into programming the game with the driving controller, and it seems like support for it is a bit flawed.. I also don't actually have driving controllers (or a whole lot of spendable money) to test that idea. xD

I used bitswitching to set up different variable states for whichever side of the screen the paddle is against. ^^ The L shape thing sounds like a great idea. Only thing is, I'm gonna be making a 2P mode with this. I don't think I'd be able to do it without creating any flickering.

How do you program it for that though? The driving controller is a bit different from the paddle controller. o.o

Here's a new game I'm working on called Quadra-Ball. It's very unfinished right now, and it's pretty much just a simple ball and paddle physics demo. (Really bad physics by the way xD) I thought I'd put it up for people to see how the game will be played. 0: Hope you like it. ^^ Update 4/26/2013: Got a new Beta version of the game up. Pretty much everything is working, except for sound. I also wanna implement a neat logo intro before the title screen. Some of the level details are still incomplete too. Quadraball_Build_BetaBuild.bas.bin

Actually this game allows the paddle to rotate around all 4 sides of the screen. I'll put up a demo soon. ^^

LOL!!!!!!!!! XDDDDDDDDD CRYSTAL YOU'RE GREAT! Okay, we gotta move this to PM's before we get banned xDDD

Thanks guys. ^^ I'm gonna use the player sprites for the paddles. That worked well. o; By the way.................. RT YOU'RE FREAKING GRRRRRRRT! XD

I'm working on a new 2600 game as my final project for my Digital Arts Associates' degree before I graduate.... but I've run into a bit of a pickle. When the paddle is at the bottom or the top of the screen, it's too short width-wise. Is there any way to make it longer than 8 pixels? o3o

Yeah, it works on an LCD tv still, amazingly. I would still rather play it on an old tube TV though, because the system was designed around those kind of TV's, so the picture actually looks a bit cleaner. There's just something awkward about the picture quality when you play an Atari 2600 on a 48'' LCD. xDD

Thanks ^^

There actually is a screen adjust. There's two buttons at the bottom right corner of the display panel, which increase the screen size. It doesn't seem to have a full screen function though. Also, bin files didn't work for you? I tried bin files of the games I wrote, and those played fine.

That's great! Unfortunately it does not support DPC or DPC+ yet. About the glitch you mention... Its not really a glitch, its intentional! Anything can happen with the real hardware if you turn the console ON with no cartridge or if you switch cartridges without turning it OFF/ON. Try and play a little with this, its funny! I tried to simulate the real hardware as faithful as possible in this kinds of situations. That makes the emulator less "plug and play", but it makes things more interesting, as you can simulate various situations that could happen easily with real hardware. For example, try to turn it ON with no cartridge, or try to force an incompatible video standard (ALT-V) and see what will happen. Hey, can you send me your games for testing? Regards, Peccin You can actually find my games in my signature at the bottom. ^^ The only one that doesn't work is Ghost, but the other 3 work just fine.

The emulator works great on Java for Linux. ^^ I got 3 of my games to work. The only game I made that doesn't work is Ghost, which uses the DPC+ kernel. Pitfall 2 didn't work either, which also uses the original version of the DPC kernel, but I thought I'd try it anyway just in case. xD There's a glitch where sometimes if you load a new game without 'turning the system off', the current score information is carried over to the next game. xD

It doesn't look like a game, it looks more like an 8-bit movie. o.o

Perhaps. I've never tried Fedora before, so I'm not going to agree or disagree. But I've got everything set up the way I like it, and I like the new improvements to the Unity bar, so I was hoping not to switch operating systems..

Luckily, this is an easy fix. If you open the unit up, you'll find that the other end of the cable is actually unpluggable from the RF transmitter box that's inside. All it needs is a regular single RCA audio cable, which you can find cheap at Radio Shack or Walmart somewhere. No soldering or splicing wires needed, just plug one end into the box inside the unit, and feed the wire through the hole in the back. ^^ I'd get one that's no shorter than 6 feet or so. Also, in the case of Heavy Sixers, the opening for the RF cable has a rubber piece that is tricky to remove and re-insert. I also have a heavy sixer that for whatever reason didn't have an RF cable, and I will never forget the struggle I had getting that rubber piece in and out of the hole. So make sure you choose a long enough wire, because it will be a bitch to replace if you find that the one you bought isn't long enough. xP

Went ahead and actually tried it. Looks like this:

Thanks. ^^ Yeah, I meant when the playfield pixels are at their default height. I always thought it was harder to read the text because the playfield pixels are normally taller than they are wide, so it stretches out the words. I think it would look less ugly if you shrunk the playfield down so the pixels are perfectly square, and if you set the kernel so there's no gaps between each pixel. You can actually do that with the DPC+ kernel too. Its really awesome how much flexibility it gives you for your games. ;o

Nothing wrong with this route as its nothing I wouldn't recommend to others. It definitely is the crux of text on Atari 2600 that the fastest best results require much in the way of prerendering and redundant data from a lack of fine division. Most of it seems to be Player object based which makes sense with them being movable and flicker/strobe compliant. The Missile and Ball don't seem to offer much character wise but I guess the linkage with the Player object and the fixed spacing values don't commingle well which I have had trouble with when designing graphics. More text is always nice but in my PC to console Text/HUD scale to overscan research, CRT based displays look better with larger fonts and uppercase primarily which has been hard to accomplish on 2600 as it seems to need sprites to be very small or very big to work using the graphics objects with gradual scale increases proving to be a difficult task. Still I tend to lean towards less visible text but better legibility as my priority, before I decided to get my eyes tested squinting from lack of glasses kept giving me eyebrow cramps. X( I'm not seeing much Playfield text mentioned yet, I found 3X? characters too big for much beyond a title screen or a short text blurb so I thought maybe Player/Missile/Ball character sections could squeeze a large font in with more characters using the Playfield for roughly half of the text render. Oh I just tried the Ghost link below your reply, looks neat but I couldn't get it to run in Stella. Another thing I also did was use playfield pixels to display a Game Over screen and some other text in another game, but if you're running the game on a big LCD screen, which is what people nowadays have, it's borderline illegible to read text drawn with playfield pixels. In my latest game, Ghost, I also use the 6-digit score area as a menu select for 1P/2P mode. By the way, not to derail from the original topic, but Ghost uses the DPC+ kernel which requires a newer version of Stella IIRC, so try that. ^^ Also, that game is my best example of how I use player0 and player1 sprites to display a variety of different text in the game, and I think it turned out quite nice.

Hi. As some of you probably remember, I recently re-did my laptop, and installed Ubuntu 12.04 on it. This time around, I wanted to try installing VisualbB so that it would run directly under Linux, rather than using a virtual Windows machine like I had been doing all along. I looked at the old topic from early 2011 that batari started about getting it to work under Linux. I installed the complete package of mono, and the other mono-vbnc package. So far, I have gotten it to the point where the ImgtoCode utility works perfectly, but VisualbB will not. It says it needs libgluezilla in order to work, but I can't find it in the Synaptics Package Manager. Has anyone else had any luck getting this to work? Or is it just a matter of time, because I understand 12.04 just came out, so not a whole lot of threads probably exist about it yet. Thanks. ^^