D.K. VCS

[Keatah]

I've never ever associated VCS coding with the demo scene. And from an unbiased layperson's point of view; I'd have to say VCS programming is a notch above demo coding. Demoscene material just makes things fly around on the screen. Crap, I can do that! I can spit on the screen, watch it splatter, and dribble into the bezel.

 

But making an engaging VCS game that has replay value and shows off the capabilities of man and machine, well now, that's a whole different story. A notch above the demoscene to be sure.

 

There's psychology, replayability, sound/video sync, good level design, character design, harmonious colors, a storyline, progression and flow of activity throughout the game. Many more aspects no doubt. All of this is not present in demoscene productions.

[Godzilla]

You are crazy, your mockups have a lot of problems - the sloping multi-colored girders to name one, the fancy colored barrels by DK for another. You don't see either of those in Joe's version.

 

 

hahaaaa :-) Indeed, but still, this is SOOOO much closer to what I was talking about. Did you see in that thread what others said was possible vs. my mock ups? The difference was quite a gulf. This version does not have that gulf. Heck, so many elements look better than my mockups now. Sloping girders and barrels If I took screenshots of Joes kong and posted them back in time, I'd love to see what was said :-)

[raindog]

I've never ever associated VCS coding with the demo scene. And from an unbiased layperson's point of view;

 

Exactly.

 

There are few people trying to make new, original games for the VCS, as you describe. (Most who are do so with Batari Basic, and rarely tread new ground.) The challenge is to see how much gameplay from more powerful hardware you can replicate on the VCS. The only psychology involved is recapturing nostalgia for your players, as evidenced by the vety thread upon which we're having this conversation. We're not oohing and aahing over the character development. We're just happy to have our childhoods un-raped by an amazing coder.

 

There are exceptions -- I know I mentioned Panky recently, either here or on another thread -- but most of us have been doing demakes of one kind or another. Look at the first page of 2600 homebrews in Al's store. Even with the ever-looming threat of copyright smackdown, we have a minigame collection full of mini-demakes, a demake, a sort-of original game, a demake, a remake of one of my demos, a remake of a calculator game, an original, an original, a Mario clone with the graphics and name changed soon enough for Nintendo to not send a nastygram, and another remake. Maybe 30% original games, 20% demo-ish stuff and 50% "just for the challenge of it" ports and clones. The "replayability" and "good level design" and "character design" and even the colors and storyline (if any) come from the source material. The other things you mention -- sound/video sync, progression, flow of activity -- are all present in demos.

 

Demo coding is all about pushing hardware to its limits, as VCS coders do -- some C64 techniques actually remind me of what we have to do in Atari kernels -- and cramming code into a tight space, and doing mathematical calculations that shouldn't be possible with so few cycles to play with, but are, due to clever techniques along the lines of what makes Ballblazer possible on the VCS now.

 

Even when they move more into game design territory, it's still the demo scene. Ever see the C64 game MOOD? It's a 3D first-person shooter. That's as crazy to do on the 1MHz C64 as Ballblazer is to do on the 2600, and it came from where? The demo scene. The company that just released GTA V started out as just some guys doing Amiga demos, one of which literally became the game Menace. Their second game, Blood Money, was more interesting for its opening demo than the gameplay itself.

 

There is definitely more to game design than writing a demo. But what most of us here are doing is not game design. It's clever code.

[Albert]

...a Mario clone with the graphics and name changed soon enough for Nintendo to not send a nastygram...

*whistles*

[Andromeda Stardust]

*whistles*

R.I.P. Princess Rescue...

http://atariage.com/forums/topic/212554-princess-rescue-now-available/

[+Random Terrain]

People code for the 2600 because of the challenge. And what are the challenges? The very limited resources! And who do we challenge? Us! And we compete with the coding heroes of our youth. If David Crane could cram great games into 2, 4 or 8K, can we do that too? Can we even become better now? Without "cheating"?

 

The main purpose for creating a game is to help make players happy (bring a little extra joy into their lives). It's hard to come up with a fairly unique game that is also fun. That should be enough of a challenge. If David Crane and other coding heroes could have used 512k cartridges, they probably would have. Homebrewers can try to limit themselves all they want, but it will never be a fair fight. The tools are much better now and more information is available. Seems like it would be better to drop the erroneous self-imposed limits and focus on making fun games that will thrill and delight Atari 2600 fans.

 

 

 

If I wanted to use the advanced hardware of today, why should I even chose the 2600, where instead I could code for the XBOX, PlayStation etc.?

Because you care about the Atari 2600 and want to do your best to make fun games for fans of the console? There's something special about the unique sounds and in-your-face graphics of the Atari 2600. (The graphics usually seem more bold, alive, and in the moment than other consoles.)

 

No amount of advanced magic stuffed into a cartridge will change what is special about the Atari 2600. Jaws will drop, drool will be dribbled, and pants will be pooped as Atari 2600 cartridges become more advanced. Shock and awe Atari 2600 fans so severely that they'll be curled up in the fetal position for a week from intense over-excitement, excessive involuntary joygasms, and extreme sensory overload.

[Keatah]

I once said, and I'll say it again, "..that the VCS is about as close to an electro-mechanical videogame console you can get - while remaining 100% electronic." It's brash, brazen, in-your-face. When you flick the joystick, I bet no more than 50 transistors process the movement and let the software know something has happened in the outside world. You are connected to the machine via wires, not drivers and interfaces and API's and modules and all that modern shit.

 

Look, the VCS was designed with a cartridge port to allow a tiny portion of the circuit to be changed. Let us use that to the best of our abilities.

[Thomas Jentzsch]

The main purpose for creating a game is to help make players happy (bring a little extra joy into their lives).

I am sorry, but in my case I have to strongly disagree. The main purpose is to make ME happy. Or do you think I would invest hundreds of hours into a game just to make other people I do not even really know happy? Homebrewing is very different from commercial game programming. For the latter you are right, else the game wouldn't sell. But homebrews are done for the fun and not for the money.

 

Of course it makes me happy if people like my results, but that cannot make up for the work invested.

 

It's hard enough to come up with a fairly unique game that is also fun. That should be enough of a challenge. If David Crane and other coding heroes could have used 512k cartridges, they probably would have.

Homebrewers can try to limit themselves all they want, but it will never be a fair fight. The tools are much better now and more information is available. Seems like it would be better to drop the erroneous self-imposed limits and focus on making fun games that will thrill and delight Atari 2600 fans.

Like have I said above, if I do not want to limit myself and want to code using modern hardware, why should I target a Frankenstein Atari 2600? The limitations are a major part of the challenge.

 

And yes, today it is easier to code for the 2600. But staying within the limits is as close as I can get. Is that rational? Of course not!

 

No amount of advanced magic stuffed into a cartridge will change what is special about the Atari 2600. Jaws will drop, drool will be dribbled, and pants will be pooped as Atari 2600 cartridges become more advanced.

True, because 99% of the people will not understand the difference. But as a programmer I do. That's why the feedback of people who know too (or at least understand) is especially valuable to me. I have cooperated in two ARM driven projects for the 2600. The results are absolutely great and some challenges, like making the game worth playing and utilizing the hardware to its best are still there. But the coding is completely different from the original one. Everybody involved into the project knows that.

 

Shock and awe Atari 2600 fans so severely that they'll be curled up in the fetal position for a week from intense over-excitement, excessive involuntary joygasms, and extreme sensory overload.

People would pack a gigahertz 64bit computer into an Atari 2600 cart, if that would be technically possible. And the results would be stunning and jaw dropping for everyone who doesn't understand the background.

 

Call me arrogant, but I do not want to impress the uninformed just for the show. I want to impress myself and other coders. That's very much like the demo scene.

 

And this is a hobby for me. I can do what I want and not what others want me to do. Making other people happy with my work is just a (very) nice side effect.

[Thomas Jentzsch]

Look, the VCS was designed with a cartridge port to allow a tiny portion of the circuit to be changed. Let us use that to the best of our abilities.

IMO, by using the ARM you do not change a tiny portion. Because besides the heavily ARM supported kernel, almost everything else runs on the ARM and not on the 6507. The 6507 code left is only a small fraction compared to the ARM code. And even that small fraction is mainly controlled by ARM computed logic.

 

Also, even though the ARM only runs ~25% of a frame, it runs at 70 MHz then. That's 18.39 MHz vs ~1.19 MHz on average (ignoring details here of course).

 

For me that's a BIG change.

 

For Boulder Dash Andrew and I spent hundreds of hours into the logic outside the kernel. The main task was to make the game fast enough with just 1.19 MHz. That was very challenging. And fun! We came up with (and often dropped) many new ideas, completely reworked parts of the code, we optimized wherever possible and saved cycle by cycle. If we had used the ARM all this challenge would have vanished immediately. We would have know from the start, that, if a C64 or Atari 8 bit can handle Boulder Dash, a modern ARM can do so easily. So why should we even bother trying? There would be no Boulder Dash for the 2600 without those challenges. Not from us.

Edited September 25, 2013 by Thomas Jentzsch

[+Random Terrain]

Like have I said above, if I do not want to limit myself and want to code using modern hardware, why should I target a Frankenstein Atari 2600?

 

If it's all on the cart, it's not a Frankenstein Atari 2600. And I already answered why. You do it if you love the Atari 2600 and want to make games for other people who love the Atari 2600. If you have no love for the Atari 2600 and only see it as a system with limited resources that you can use to challenge yourself and impress other programmers, that sucks.

 

 

 

 

I am sorry, but in my case I have to strongly disagree. The main purpose is to make ME happy. Or do you think I would invest hundreds of hours into a game just to make other people I do not even really know happy? Homebrewing is very different from commercial game programming. For the latter you are right, else the game wouldn't sell. But homebrews are done for the fun and not for the money.

 

I don't care if you get paid or not. You can have fun expressing yourself and challenging yourself, but the main purpose for making a game is to give joy to the people who will play it.

 

 

 

 

People would pack a gigahertz 64bit computer into an Atari 2600 cart, if that would be technically possible. And the results would be stunning and jaw dropping for everyone who doesn't understand the background.

 

Who cares? If it doesn't impress other programmers because you are 'cheating,' they can eat warm dog crap off a sidewalk. Games are for players. If a game is fun, it doesn't matter what other programmers think.

 

 

 

 

Call me arrogant, but I do not want to impress the uninformed just for the show. I want to impress myself and other coders. That's very much like the demo scene.

 

As I have said in this thread and on this page of my web site, you are supposed to make games for players. You can have fun expressing yourself and challenging yourself, but players should be your main focus. Calling them uninformed and only wanting to impress yourself and other programmers shows your lack of love for players. I've had the following on my web site for 13 years in the hopes that people like you would read it and change their ways:

 

"'The player is paramount' is a phrase all game developers should remember. Great game designers have a certain amount of love or respect for their players. If you're not helping your players feel happy and fulfilled in some way, then you shouldn't be making games at all. Don't make games just to express yourself or to impress other game designers or programmers. Think about the players too. If you make games that are fun and satisfying and put in the effort to add extra little touches, players will feel like you really care and they'll love how you went out of your way to delight them."

 

 

 

 

And this is a hobby for me. I can do what I want and not what others want me to do. Making other people happy with my work is just a (very) nice side effect.

 

Me, me, me, me, me, me. Game design is about bringing joy to the world. Making people happy shouldn't be a side effect; it should be your main mission. This is also on my web site:

 

"Too many games are made for the challenge of it, without seeming to care that much about players. Even though players are important, their reactions should only be taken as feedback you can use to make better games. Player comments shouldn't feed your ego or damage your self-esteem."

[Keatah]

With honorable respect to all opinions expressed.

 

Wasn't the original intent of Atari to have something like 8 VCS cartridges? And some internal delay or politics pressed the VCS into overtime duty - another year?

 

 

If I put my purity hat on I feel that anything beyond 2k and 4k is bastardized against the original intent. Anyways in the heyday programmers no doubt welcomed expanded carts and trick bank-switching schemes, and it was part of the pioneering effort. Progress. Part of developing the platform. But the consumer didn't care what the address lines were doing. Or what vblank was. The consumer would just recognize something was special about a game or series of games. I tended to associate non-flicker with Activision. Or good contrast and luminance effects with Imagic. But no more! The consumer might make the judgment of whether the programmer was any good or not by how badly the game flickered. Or if it was fast. Or by the depth of the sound effects.

 

The consumer knew little about how big a Game Program really was. Crap. I didn't know how small they were until I got into emulation and looked at the size of the dumps. All I knew at the time was that Intellivision had more ROM space than VCS, especially because the cartridges typically had two chips as opposed to one in a VCS Game Program. That's what a consumer sees. That's what a gamer sees.

 

I didn't care about any of the programming techniques. About all I knew is that the games were in some kind of special code that was different from BASIC. That and the fact that they were in ROM. And ROM was faaaasssttt! Much faster than the BASIC I would write and store in RAM. And at the same time, I was keenly aware of trimming down the last 10 bytes on my BBS software and its mods on my Apple II+.

 

Despite all the innocence and simplistic ways of looking at things, I enjoyed the stuff. I played the games. I was happy.

[Thomas Jentzsch]

Me, me, me, me, me, me.

Even though we heavily disagree on the topic, you still got me right.

 

Now you can stop telling me how you want me to be.

Edited September 25, 2013 by Thomas Jentzsch

[Thomas Jentzsch]

If I put my purity hat on I feel that anything beyond 2k and 4k is bastardized against the original intent.

I suppose everybody has its own hat here. Which is absolutely fine.

 

Which is not fine is, if someone thinks everybody should wear his hat.

 

And at the same time, I was keenly aware of trimming down the last 10 bytes on my BBS software and its mods on my Apple II+.

So you understand the motivation. What was the Apple II+ to you back then is the 2600 to me now.

 

I didn't care about any of the programming techniques. ...Despite all the innocence and simplistic ways of looking at things, I enjoyed the stuff. I played the games. I was happy.

So did I. But over time my knowledge and point of view has changed. The reason why I returned to the 2600 (which I had completely forgotten in between) were not the games, but the absolutely unique challenge it offered. The love for the system returned later. Edited September 25, 2013 by Thomas Jentzsch

[Andromeda Stardust]

@RandomTerrain: You are right in saying that the programmer makes games to please the gamer,however you are wrong to infer that the gamer necessarily has to be someone else. I made a lot of crappy games on my TI-83 back in the day. The basic games were slow and they sucked for the most part, but I enjoyed coding them and playing my own creations. A couple of my friends got to test them out, but they were my creations. I did not make them for the enjoyment of others but simply as a way to entertain myself during study hall. I even at one point made quite a good craps (dice) simulator with adjustable bets and animated dice. Sadly, an unfortunate incident involving depleted batteries corrupted the RAM memory and all my hard work got erased.

 

As a game coder, you have to tune out the whining but allow suggestions and constructive criticism. However, if the programmer makes him/herself a slave to the whiners and complainers, it ceases to be fun and the game usually remains unfinished. Nobody was posting in a web forum begging me to release my TI-83 craps simulator, or even knew about it before I finished the game, because I made it for my own amusement. I even included an Easter Egg whereby setting a certain variable to a certain value prior to running the game would result in "loaded" dice (the first die was a 5 and the second was a 2 or 6, summing up to 7 or 11 every time). If you win over a certain amount, the game checks this variable. If you won the money playing fairly, a congratulatory message was displayed. If you used the Easter Egg cheat, your winnings were confiscated.

 

Back to what I was saying, homebrew programmers program primarily because they enjoy coding their own games. If they share their creations with the world and everyone loves it, well that just leaves a warm fuzzy feeling in the programmer's heart. But the primary motivator comes from the programmer, not the fans. Similar situation with music. Most people start making music because they enjoy it, and if they are good enough, others will enjoy it too. Few earn a living doing it as most weekend performers have day jobs that pay the bills. Very few ever become pop/rock stars with multiplat albums.

Edited September 25, 2013 by stardust4ever

[+Nathan Strum]

You have to enjoy the process. If you don't, you stand no chance of making a game that is fun for anyone.

 

The game has to be enjoyed by its creator(s) first. Otherwise, they're just second-guessing their audience. It's like when movie studios make movies aimed at kids, that are horrible to watch for adults. If the filmmakers enjoy the movie they're making in the first place and don't try to dumb it down for kids, kids will enjoy it anyway, and adults will enjoy it too. Unless the filmmakers are just really bad. Which, you know, almost never happens.

 

Everyone has their own valid criteria for working on homebrew games. If your goal is to make a game you want to make, that's valid. If your goal is to make a game for other people to enjoy, that's valid too. If both goals coincide - bonus points. This is a hobby. Not a commercial enterprise. The enjoyment of a hobby should be defined by the participants in it. In this case, the programmers. If I enjoyed basket weaving for the sake of making baskets, my enjoyment of it shouldn't hinge on whether or not someone will want to buy one and find it useful. On the other hand, if my enjoyment stems from making useful baskets for other people, that's a different criteria, but the important point is: it's still my criteria. Nobody else gets to define it for me, or has the right to tell me I'm wrong. Not unless they're paying me to make baskets for them.

 

From my standpoint, I respect attempts to make games within historical constraints. Knowing that such games could have existed back-in-the-day is pretty cool. Then again, I really like the idea of continuing in the vein of things like the SuperCharger or RAM Plus carts, to really push 2600 games to that next level. I tend to favor the former over the latter, but at the end of the day, if I can plug a cartridge into my 2600 and play a new game on it over 30 years after I bought the thing... then I consider myself pretty lucky to be the recipient of someone else's hard work, and to enjoy the benefits of their hobby.

[Godzilla]

There is a difference between making art for arts sake made for the self (fine art,) and art made for commercial purposes. I think that is the crux that is being missed here. TJ is more interested in creating works of fine art and you are more interested in creating commercial art. Nothing wrong with either approach and as TJ said, he is free to be he and you are free to be you. Let's try not to tell each what to be. Just my two cents.

[+SpiceWare]

True, because 99% of the people will not understand the difference. But as a programmer I do. That's why the feedback of people who know too (or at least understand) is especially valuable to me. I have cooperated in two ARM driven projects for the 2600. The results are absolutely great and some challenges, like making the game worth playing and utilizing the hardware to its best are still there. But the coding is completely different from the original one. Everybody involved into the project knows that.

Yep, the challenges for the ARM projects are different, with some overlap. Thomas' help has been invaluable, my current project (to be announced at PRGE) has turned out significantly better with his support - his expertise with TIA and memory usage optimizations continue to astound me.

 

I did a lot of 650x development back in the 80s on my Vic 20, C= 64 and C= 128. What attracted me to 2600 development wasn't the 650x, but the challenge of making TIA create a display in real time with only 76 cycles of CPU time per scanline. I don't have any qualms about using things like DPC+ or bus stuffing to make fuller use of those cycles; after all, it's a continuation of what was done back in the day with Pitfall II and The Graduate.

 

[+Random Terrain]

Now you can stop telling me how you want me to be.

 

I'll keep trying to bring you from the dark side as long as my fingers can type.

 

 

 

 

Which is not fine is, if someone thinks everybody should wear his hat.

 

I know that you love your black hat, but I'm still going to try to convince you to switch to a white hat at every opportunity.

 

 

 

 

. . . however you are wrong to infer that the gamer necessarily has to be someone else.

 

It's pretty clear that most homebrewers want other people to play their games. They can have fun expressing themselves and challenging themselves, but the thing at the top of the list should always be making a fun game. If impressing other programmers with your elegant code is higher on the list than making a fun game, you might as well just make demos and forget about games.

[Thomas Jentzsch]

I'll keep trying to bring you from the dark side as long as my fingers can type.

No thanks, it is perfectly bright on my side.

 

I know that you love your black hat, but I'm still going to try to convince you to switch to a white hat at every opportunity.

Sounds like a threat to me. Are you on a holy mission or what?

 

It's pretty clear that most homebrewers want other people to play their games.

Me too.

 

They can have fun expressing themselves and challenging themselves, but the thing at the top of the list should always be making a fun game. If impressing other programmers with your elegant code is higher on the list than making a fun game, you might as well just make demos and forget about games.

Doing demos would be soon boring for me. They are not interactive and have little replay value. Therefore I prefer creating games. They have lots of additional challenges. Why should I restrict myself where I do not want to?

[+Random Terrain]

Doing demos would be soon boring for me. They are not interactive and have little replay value.

 

You could always make interactive 2k demo art for museums.

[Keatah]

(These days I spend time researching physics & Quantum Mechanics and how it all comes together to make your 4TB mechanical disk drive operate. How can we get the next jump in areal density? That and the black art of data recovery - bringing multi-disciplinary fields together to effect a repair when a mechanism goes bad and takes tens of thousands of dollars of work with it. And now with the SSD era coming of age, a whole new playing field is opening up.)

 

NOW on topic:

Now..now.. To me, the core of the VCS is RIOT and TIA, and of course that little snippet of 128bytes of ram. As long as those parts aren't changed out or modded then everything is golden. And the 6507 sits off to the side commanding everything. Simplistic? Probably.

 

What I would like to see, while working within the restrictions I illustrated above, is some type of full motion video done on the VCS. What would it look like?

[Keatah]

 

You could always make interactive 2k demo art for museums.

 

 

Ohh god please no!! This kinda crap is so Nuvo and Couture. I don't understand that crap! This "high art" is so snobbish, complex, and incomprehensible.

 

I remember Slow Year, not because of the content, but because of the $500 box. IMHO that genre has already been filled and there is no room left for new material there.

Edited September 25, 2013 by Keatah

[Bryan]

Boy, this thread sure changed since the last time I checked it. I get into the same debates with A8 upgrades. At some point the vintage computer only serves as a terminal to the hardware doing all the work, and what fun is that? I can buy a fairly kick-ass PC motherboard for $50 and save myself a lot of soldering. But this hobby is different things to different people.

[raindog]

What I would like to see, while working within the restrictions I illustrated above, is some type of full motion video done on the VCS. What would it look like?

 

Well, that's pretty open-ended. Here are some possibilities: A 128-color, flicker-free 11x200 (or less) display (yes, that's 11 as in ten plus one -- the best you can do if you brute-force LDA/STA color values to change the background color and ignore the players/missiles/playfield altogether), a slightly flickery 8256-color ~23x200 display, a seizure-inducing 96x200 flickerfest with CGA colors and solid bars on the sides, a shimmery 96x200 display that's close to monochrome (striped at best) and has bars on the sides, a rock-solid 40x200 full-screen monochrome display, a shimmery 40x200 full-screen display with CGA colors, a seizure-inducing 40x200 full-screen display with 10 colors... those are the easy ones, off the top of my head, but your vertical resolution would have to be reduced a lot to get a good-sized loop into 32k, especially with the first two techniques.

 

Monochrome literally means you get 2 colors, the background and the foreground. 128 colors is the full 2600 palette. 10 colors is the unique combination of 4 colors (i.e., 15Hz flicker). CGA colors are the unique combination of 2 sets of 2 colors with 30Hz flicker (if you start with red, green, blue and black, you get one of the two CGA color palettes[*], which was dark red, dark green, cyan and magenta), or 15Hz if you're doing the 96 pixel thing. 8256 colors is what you theoretically get when you have the full VCS palette on 30Hz flicker and every other frame horizontally offset by half a "pixel" (unique combinations of two out of 128 colors). With any of the non-monochrome techniques, anything with a lot of camera movement will probably dissolve into a hash of pixels since each frame of video is displayed across 2 or 4 frames displayed by the 2600.

 

In other words, there are a lot of options, but probably not really a way to do something like "Dragon's Lair". Though I bet it would be funny to do a 20x20, 8256-color Dragon's Lair on the Harmony with each new section loaded from the SD card. The blank screens during the load time would be a tip of the hat to the authentic Dragon's Lair arcade experience, with the laserdisc players needing a few seconds to seek between scenes on a good day.

 

I've expressed opinions on both sides of this debate, and I think both are valid. I consider it cheating if your C64 demo requires a 20Mhz processor and a hard disk, but the 2600 is different because the hardware is the hardware and all we have access to is the cartridge slot and controller ports. Pitfall II was not cheating in my book; neither was Mountain King or any of the other games with extra RAM. So, the Harmony isn't cheating either, but it's a different ballgame. I see the value (and challenge) in 2K and 4K demos, and in "let's see how far we can push this" Harmony projects (obviously, since I own one). In addition to the challenge factor, there's the "how many people will ever be able to play this on real hardware?" factor; there are several orders of magnitude more 2600 owners who don't have a Harmony cart or even a Supercharger than those who do.

 

But it's the coder's choice, not the would-be audience's. If I can do something in 4K, that's my preference, but oh, the toys we have now. (And that applies to development tools, coding techniques and even the community, not just exotic hardware.)

 

Edit: *no, that wasn't one of the CGA palettes, it just looked like one when I visualized it, and there were apparently more than two CGA palettes.

Edited September 25, 2013 by raindog

[killersquirel]

Yep, the challenges for the ARM projects are different, with some overlap. Thomas' help has been invaluable, my current project (to be announced at PRGE) has turned out significantly better with his support - his expertise with TIA and memory usage optimizations continue to astound me.

 

 

 

 

I would like to say that I'm extremely excited for your new project. Am I correct in assuming it will use an ARM processor? I just want to publicly thank you for all the games that you've released so far. They are all amazing and above all extremely fun to play. Keep up the great work!

 

-mike