Jump to content
RevEng

7800basic beta, the release thread

Recommended Posts

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.

  • Like 4

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :) :thumbsup:

 

I will say that I always viewed bB (and now 7800basic) as a rapid app development environment. It's all relative, I guess. :P

Share this post


Link to post
Share on other sites

I will say that I always viewed bB (and now 7800basic) as a rapid app development environment. It's all relative, I guess. :P

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
post-34988-0-89011700-1423625675_thumb.png
Can you tell which is Stella and which is GameMaker?
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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!
  • Like 9

Share this post


Link to post
Share on other sites

"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?

Share this post


Link to post
Share on other sites

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.
  • Like 3

Share this post


Link to post
Share on other sites

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.
  • Like 5

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 :)

  • Like 2

Share this post


Link to post
Share on other sites

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.)

  • Like 7

Share this post


Link to post
Share on other sites

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.)

 

post-4460-0-15407700-1428797715_thumb.png

splitmode.bas.a78

splitmode.bas.bin

Share this post


Link to post
Share on other sites

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.

 

post-23476-0-59230800-1428800282_thumb.png

 

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)

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...