Gemintronic

On the other hand, Boulder Dash may end up being the ONLY tile-based game released on the platform.... ever. Is the source too tied into the specifics of Boulderdash? Or, are you saying there's not enough assembly coders out there to carry the torch? Being the first and only sounds like a pretty lonely place.

The people who will buy this: A. Want to own a new Jaguar game B. Like the extra features (BJL loader) of the cart That wont change even if the developers get kidnapped and put on a pirate ship full of pirates and ninjas each stealing a cart from eachother. Nothing has changed in my view.

rem Compiler Options set smartbranching on set romsize 4k rem These are basic settings for a simple game. smartbranching never hurts. We don't need multi-bank so 4k. rem Declare variables dim xpos = a dim ypos = b rem bB doesn't always work right with temp variables and doesn't like alot of caclulations on one line. We're gonna use up two variables for the playfield pixel position. rem Startup code init COLUPF = $0E rem Put code here that should always run before the main program begins. In this case I'm setting the playfield pixel color to white. rem Main loop main xpos = rand&3 ypos = rand&3 pfpixel xpos ypos flip drawscreen goto main rem Like I said, bB wont let us do pfpixel temp1 temp2 or lots of calculations like pfpixel 0 (rand&3) flip so we have to break it down.

I had probs compiling with my version of bB. Here is some version info: batari Basic Compiler date (1/31/2011 12:15:04 AM) Current bB compiler version supports -O option. Peephole optimizer option enabled. Current bB compiler version supports DPC+ Kernel. DPC+ options enabled. DASM V2.20.07, Macro Assembler ©1988-2003 Basically, the bB with SDATA statements broke. I took out the comments at the top and put in a line break between the first pfcolors and playfield data to get it to compile: set kernel_options playercolors player1colors pfcolors set tv ntsc set romsize 16k set optimization speed set smartbranching on set optimization noinlinedata set optimization inlinerand rem set debug cycles const pfscore=1 init pfcolors: $42 $1A $42 $42 $42 $42 $1A $42 $C6 $C6 $3E end playfield: .......................XXXXX.... ......................X......... .................XXXXX.......... ................................ ................................ .................XXXXX.......... ................X.....X.....X... .......................XXXXX.... ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end

Part of the 2600s charm is its simplicity. It was literally only supposed to play pong. One is forced to focus on gameplay and as a side-effect replayability and novelty. On the other hand Atari 2600 has also always represented the infinite capability of programmers minds. It was STILL competing with the 7800, Sega Master System and NES when I grew up. Games like Double Dragon, Ikari Warriors and Commando proved we could strech its reach further. Tile based graphics have been tried before and ALMOST made it. I remember the Homestar Runner demo and other partial examples. Boulderdash is what makes tile based engines real. I hope somehow this becomes a template for other tile based 2600 games. Perhaps someone could write up a tutorial and basic template for those assembly coders. You guys could be the first to enable a new generation of tile based homebrew. That might even be bigger than Boulderdash II

I think this is a good idea. Er, wasn't there supposed to be some sort of homebrew tracking features built-in to AtariAge? I'd assume it was more than this: http://www.atariage.com/development_list.html

I usually post my source and put the compiler error in a code box in my post. Sometimes it's just a matter of an extra pair of eyes. Also, I'd make it a habit to save versions every major change. That way you can backtrack if needed to compare differences when debugging. If it's an issue with too much sprite data then you can try making the sprites more friendly to REFP0, REFP1 based animation. I'd say the Goombas would be an excellent candidate for this kind of animation.

Has anyone ever come up with an "ultimate" graphic character block font? I know the Aquarius set is pretty good. C64 as well. Has anyone tried to make a common graphic character set to rule them all?

Hey! Since you know what you doing, do you think the Reality Coprocessor and the Jag processors are similar? If not, why?

I was actually fishing to see what you fellows think about this IP business. I mean, does it suddenly become art if it includes sprite-like characters? Could one use the Aquarius character set free and clear? Only the ghost of Radofin knows for sure..

It's still the plan, for the most part. If I can get all the boxes (for the 2012 and 2013 titles) printed this year, then that will leave the manuals, which isn't nearly as much work as the box templates. It takes me about a week to write up a single manual, so it's not too bad. Assembling carts and gluing boxes together is time-consuming, but again, it's not something that requires months and months of work. So the 2013 BasicVision plan still stands, although it may take me more than a year to complete the parser and all the auxiliary editors, given that I'll have to beta-test certain games, like The Black Onyx. I followed newcoleco's course on the CV BIOS sound format at AdamCon, and it made me realize how much work it's going to require just to acquire a good understanding of how to make music and sound effects on the CV. I had an easier time with Dale Wick's assembly language course, but his code examples relied heavily on the CV BIOS routines, so there's still a lot of stuff to learn on that front. Until I've sufficiently mastered sound output and assembly programming, BasicVision will remain an empty shell of an application. It may be more basic (ha!) then it seems. Somebody has already done a preliminary port of ZX Basic for the Sega Master System: http://www.smspower....pic.php?t=12902 If you could scavenge his framework and convert over the Sega specific code then you'd be much farther along, methinks.

Some of these companies and brands are still alive. Someday those companies could decided to cash in and make DLC and start taking notice like Atari has in the past. Is there a backup plan in those situations? I wouldn't mind a rename and sprite swap for Wonder Boy if Hudson Soft ever decided to be a butt-monkey.

At present you can get a Raspberry Pi and case for around $50. Given $35 for the unit and $15 for the case. No restrictions or DRM. You want RiscOS? Change the SD card. You want Internet TV? Boot into XBMC. Debian means plenty of emulators to be easily ported over. Stiff competition I'd say.

That is a cool thought. Until you realise you have no control over this virtual property. You post an unfavorable opinion on Splatman Rises and the movie production company yanks your ticket. Viabomb and Yetti & T have a dispute over who owns the rights to your e-book and it gets ripped out of your library when the opposing side wins. @ LOON, What in the hell are you talking about now? Seriously, I have no clue what the post that I quoted that you wrote could possibly have anything to do with the OP's original post. Vaughan points out the future (virtual propertty) then someone comments it's a cool thought THEN I point out the downside to the next big thing. Buying and selling in game seems neat-o. Really, you don't own the online game. You don't own the property and it's not even really on your computer. You personally pay but you control none of it. The next big thing wont be the console it's on. It's the fact we are giving up physical property and personal ownership. @ MXYZPTLK, If you feel the need to point out the insanity of my viewpoint then take a good hard look at my nickname and walk away.

1. Release RaptoR API/Scripting engine to the masses 2. Receive developers (and bacon) 3. 1 out of 1000 devs will have experience with Jag and USB coding. Makes the new Jagsputer with EMUTOS and MiNT.

I always thought you sat a buddy in an office chair, gave him a shot of Bacardi 151 for each dozen spins and spun him around 'till he loses!

Here's a topic about fixed point math: http://www.atariage.com/forums/topic/126179-another-cool-thing-fixed-point-math/ It may be retarded but you could probably simulate numbers like 1.3 by using two variables.

I'm not ignoring you dawg I'm behind on my own coding (my own fault). Hopefully someone will whip up or link to a good example.

He made a Genesis version as well: http://devster.proboards.com/index.cgi?board=basiegaxorz&action=print&thread=721 He's one of those homebrewers that try to create a game for every system they can. I say the more ports the merrier! In fact, I'm trying to see if I can get permission to convert Get Lost to the Genesis.

Artwork would be a bonus item. Include the game in an easy-to-launch fashion. Make it like a Williams Greatest Hits kinda thing. Provide Interviews and insight from the homebrew authors. make it something you can gift to a non-computer literate friend or family member.

And it still is. Maybe I came off a little snarkey. I guess what I'm looking for is an explanation why this is unique? Hasn't vertical scrolling been figured out for quite some time?

There are minor revisions to modern game consoles in order to reduce cost or fix problems that become too public. Most firmware updates are actually security fixes that interact with the hardware at a low level in order to block consumers from freely using their property. Unfortunately, since there are minor revisions of XBOX 360s and PS3s and different tolerances for heat and wear some unexpected oopsies can occur - including locking dead your console.

I can't really compare the two. All I can think about is magically snatching that RAMBUS memory from the N64 and putting it on the 64 bit memory interface of the Jag... yummy!

The ring animation is awesome. The variable jump is nice. Good use of flickering to get that boss monster looking right. I'd work on the collisions though. You can run right through the entire level. You can use the stalled falling effect to enter into the sides of the floor. Also, if you keep pressing into the right side of the screen at the boss you can eventually fall through. I'd correct the issues and then use what you've learned to create a new game. it can even have the same sprite and similar engine. Just finish this mini game enough to be OK with it and then move on. Moving on is hard but completing things means you can gloat over it

I thought smooth horizontal scrolling was the naughty no-no uh uh cannot do thing on the 2600?