RevEng Posted February 10, 2015 Author Share Posted February 10, 2015 How much programming knowledge would I need to know for this game? I did Windows (mostly C, some C++) programming for a few years, and I still remember some of the Java class I took way back in college. I've never touched Basic, though. It's not really a requirement that you know BASIC previously. You'll just have to pick up how the syntax differs from what you know. Its a bit hard to say if what you know is enough to tackle a specific job. The most important skill you'll need is the ability to break down a problem into small steps. If you have that, then it's just a matter of time as you familiarize yourself with how to do those steps in 7800basic. (or assembly, if you choose that route) Regardless of the language chosen, Amidar is best tackled with a RAM based character display, since the background changes as you move across it. The player and enemies can be drawn with sprites, and you'll need to check the characters underneath your player so you can limit his moves to certain directions. Finally, the best bit of advice I can give is to not try and make the first thing you code be your dream project. As you learn a new language and environment, it's best to try several small throw-away programs, until you're confident enough that you have the skills to tackle that dream project. 4 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted February 10, 2015 Share Posted February 10, 2015 Finally, the best bit of advice I can give is to not try and make the first thing you code be your dream project. As you learn a new language and environment, it's best to try several small throw-away programs, until you're confident enough that you have the skills to tackle that dream project. Would you recommend making the game in 7800basic from the start, or prototyping in something else, like GameMaker? Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 10, 2015 Author Share Posted February 10, 2015 I think if you're prototyping a game on a more powerful platform, the prototype may not translate all that well to 7800 when you're ready to make that move, especially if you're less familiar with the limitations of the 7800. Bear with me if I get a bit lofty here, but I've always been a fan of letting the resistance of the medium guide my work. You might pigeonhole a design from another platform into the 7800, and you might do a good job of it, but there's something intrinsically interesting about a game designed to mesh with the hardware in an organic way. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted February 10, 2015 Share Posted February 10, 2015 I think if you're prototyping a game on a more powerful platform, the prototype may not translate all that well to 7800 when you're ready to make that move, especially if you're less familiar with the limitations of the 7800. Well, I presumed one would make efforts to emulate the style of the 7800 to make things more accurate. The speed in development would more come from the convenience of objects in modern engines versus the abstracted sprites/limited memory of classic systems. It would indeed require careful effort to make sure that the screen resolutions were identical so that algorithms one develops, like jump/attack arcs, could translate directly (more or less) from the higher-power system to the retro system. I was particularly pondering this in the case of batariBasic programming; designing the systems that allow things to efficiently work takes a long time and is difficult in batariBasic (and presumably 7800basic as well). Maybe I'm blowing smoke, but I'm hoping that prototyping would be helpful in speeding up design, rather than requiring the entire game to be rewritten from the ground up a half dozen times as plans and requirements change. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 10, 2015 Author Share Posted February 10, 2015 It could well be a benefit to some developers, but I wouldn't generally recommend it unless you're very familiar with the 7800. It's not just the resolution. You also need to keep in mind the active sprite count (vs ones you've already baked into the display with "savescreen"), the palette management, finite RAM, finite ROM, finite CPU cycles per frame, etc. I agree with the approach generally if you're trying to see if a novel game mechanic is fun. In that case I'd go ahead and throw together something in whatever I could code the quickest in, and truthfully wouldn't care to adhere that closely to the 7800 limitations. Past that initial fun-test, I'd switch to the real deal, so I can see the limits when I run up against them. But my workflow may not work best for you. Give it a shot and share how it works out. I will say that I always viewed bB (and now 7800basic) as a rapid app development environment. It's all relative, I guess. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted February 11, 2015 Share Posted February 11, 2015 I will say that I always viewed bB (and now 7800basic) as a rapid app development environment. It's all relative, I guess. I wouldn't say bB is, particularly since everything has to be done super-carefully or else you're out of cycles/memory/space/all-of-the-above. On that note (though this isn't quite so 7800-based), this is my result after a couple hours of building a way to take in the levels and spit out a recreation of what you'd see on the Atari2600, along with the original from Stella: ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXX......................XXXXX XXXX........................XXXX XXX............................. XXX...XX.XX..................... XXX............................. XXX...XX.XX..................... XXX............................. XXX............................. XXX........XXXXXXXXXXXXXXXXXXXXX XXX.......XXX................XXX XXX......XXX.................XXX XXX.....XXX..................XXX XXX....XXX...................XXX ........XXX......XX.XX.XXX...XXX .........XXX...........XXX...XXX ..........XXX....XX.XX.XXX...XXX ...........XXX.........XXX...XXX ............XXX........XXX...XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Can you tell which is Stella and which is GameMaker? 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 11, 2015 Author Share Posted February 11, 2015 Nope, no idea. Quote Link to comment Share on other sites More sharing options...
SIO2 Posted February 11, 2015 Share Posted February 11, 2015 Top one is Stella. Quote Link to comment Share on other sites More sharing options...
Cybearg Posted February 11, 2015 Share Posted February 11, 2015 Top one is Stella. Mhm. Still, close enough for prototyping purposes, IMO. Quote Link to comment Share on other sites More sharing options...
Mord Posted February 11, 2015 Share Posted February 11, 2015 When it comes down to it, different people prefer different approaches to the problem. The question you have to ask yourself is if you feel you're going to be saving time overall by doing it that way, or do you think you might be changing what you're doing in the development cycle - ie: While you may get a finished product in Game Maker (or whatever) fairly quickly, and it'll give you a good idea of what you want to accomplish, you might end up spending a lot more time trying to get that to work on the target hardware, making compromises, rebuilding for efficiency, cutting back animations, trying to find places to put everything in the rom assuming it'll fit, etc. For some, that's an acceptable trade off. Others would prefer spending more time on the actual hardware to begin with, gaining familiarity with the limitations first hand. There's no one correct way to do it. 1 Quote Link to comment Share on other sites More sharing options...
Jess Ragan Posted February 11, 2015 Share Posted February 11, 2015 I should get back to this someday. I was making pretty good progress on my game until I lost interest. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 22, 2015 Author Share Posted February 22, 2015 The lastest 7800basic release, beta 0.3 20150222, is now in the first post. Here's the changelog excerpt... added speechdata and speak commands, and atarivoxspeech sample program. reallocated DL memory to maximize the number of possible objects in each zone. fixed issue with background color not fully being B&W when the game is paused. loosened the restrictions on the number of color indexes within a png, vs used colors. added "set zoneprotection on" command. converted internal error, warn, and info functions to use printf style arguments. Cheers! 9 Quote Link to comment Share on other sites More sharing options...
gambler172 Posted February 22, 2015 Share Posted February 22, 2015 Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted February 22, 2015 Share Posted February 22, 2015 awesome addition for speech. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 22, 2015 Share Posted February 22, 2015 Online version updated: randomterrain.com/7800basic.html If anyone finds any mistakes, please let me know. 4 Quote Link to comment Share on other sites More sharing options...
Mord Posted March 26, 2015 Share Posted March 26, 2015 "set tv" I see this config in the samples, and of course end up using it by default, but I don't see it mentioned on the website. Could it get added so we (or at least I!) know exactly what it's doing and if there's anything it does that I can make use of directly? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 26, 2015 Author Share Posted March 26, 2015 Ah, I didn't realize I had let that slip into the samples. At this point, "set tv" does exactly nothing. It was meant as a placeholder, but I went another way with PAL support... I ensured that both NTSC and PAL will get enough blank lines to keep them happy. I added the "paldetected" variable, that you can use to change the game speed/behavior. If you really want to cater to PAL consoles, you can increase the vertical resolution to 224 with "set screenheight". That will push the limits of an NTSC display and ensure that PAL folks have less wasted screen real estate. Eventually I'm going to fine tune the png->7800 color conversion routines to more accurately reflect NTSC and PAL. (right now the phase is a bit off) At that point "set tv" will probably be used, to tune the routine one way or another. 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 30, 2015 Author Share Posted March 30, 2015 There's an updated 7800basic in the first post. The main addition is the high score table functions. These work with saving HSC, AtariVox, and SaveKey. If the user has none of these, the high score table will still be displayed, but lost when the console is turned off. Here are the main updates... added drawhiscore command, with support for saving score tables to the HSC, AtariVox, and SaveKey. added loadmemory and savememory commands, for saving data to HSC, AtariVox, and SaveKey. added NOTIALOCK constant to startup.asm, for programs what wish to access the BIOS underneath the cart ROM. fixed issue that would cause some on-screen plotvalues to sometimes shimmer. modified dmahole statements to no longer interrupt code flow. If anybody wants to see the high score tables in action, I've added them to T:ME Salvo. 5 Quote Link to comment Share on other sites More sharing options...
MobiusAqua Posted March 31, 2015 Share Posted March 31, 2015 Epic! Thanks for the update. I'll have to check one of my projects for the "shimmer" bug. And a question, if you don't mind: I've heard that the new AtariVox+ has some sort of a sound generator? Will a future version of 7800basic possibly support that feature, as well? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 31, 2015 Author Share Posted March 31, 2015 Yeah, all of the AtariVox have a tone generator built-in, which theoretically could be used for music. You can actually play with it now, by sending the data to control it, though it takes a number of bytes for any note-on or note-off event, so there's a fair bit of latency. I was planning to look into it a bit more when I got around to adding better music support 2 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 1, 2015 Share Posted April 1, 2015 Online version updated: randomterrain.com/7800basic.html If anyone finds any mistakes, please let me know. (Nobody has to "like" this post. I'm just letting you know that I think the online version has all of the latest changes. I hope I didn't miss anything.) 7 Quote Link to comment Share on other sites More sharing options...
Mord Posted April 12, 2015 Share Posted April 12, 2015 I've been tinkering with the splitmode sample lately (On Linux) and I noticed, after adjusting the palette settings to load from the incgraphic constants, that the colors are off. I'm using prosystem v13e since I can't really get mess working right now. When I compile the adventurer.bas sample, the colors look fine. Is this an emulator issue with switching display modes on the fly, or something else? Attaching bin and a78 if anyone wants to verify if it looks like what I see. (You can probably guess what I'm doing with that 320A mode from the screenshot.) splitmode.bas.a78 splitmode.bas.bin Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted April 12, 2015 Share Posted April 12, 2015 Looks just like that on real hardware, just fired it up on my devcart. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 12, 2015 Author Share Posted April 12, 2015 Looks less orangey on my deck. Much closer to the MESS output, but not all the way. Of course, that depends on how you've tuned your deck. (or how it's been tuned before you got it) and your TV too. That said, the PNG to Atari NTSC color space conversion is an inherently imperfect process. I have plans to dial it in a bit closer, but the auto import will never substitute hand tweaking the colors. (which you can do just by adding or subtracting from the color constants, if you like) Quote Link to comment Share on other sites More sharing options...
Mord Posted April 12, 2015 Share Posted April 12, 2015 So something to keep in mind while I try to pretend I can do sprite art. The importer was actually doing a pretty good job with some of the sprites I was doing earlier for some tests, so I guess this caught me a bit off guard. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.