Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by Cybearg

  1. Amazing word, Pac-Man-Red! You're very talented!


    I'm a little confused about some of the sprite examples you've given, though. Forgive my ignorance, but I assume that with most of the spritesheets you've posted, the Zelda sprites are on the left and you give your own take on the right. I noticed in a couple instances, though, that your versions use 4 colors instead of the limit of 3 (such as with the compass and book sprites in this post). Are those just rare examples where a sprite would actually be made up of two overlapping sprites (as would need to be the case for the supersprite of the bosses you posted above)?

  2. For anyone interested, I've made a little command line tool called pngParse that reads a palette png image and a sprite png image and outputs sprite table data formatted for batariBasic or 6502 ASM.



    Notes on use:

    pngParse doesn't approximate colors: it identifies colors between the sprite image and the palette image by comparing r/g/b values, so for your sprite image to accurately be parsed, its colors must exactly match the colors in the palette.


    pngParse can take custom palettes of 8x16 pixels. Palettes for NTSC and PAL are already included in the attached zip file. if you don't specify a custom palette file, pngParse will expect to find ntsc.png or pal.png (depending on the -P flag) in the same directory. Output will go to output.txt by default.


    Sprite images must have a width divisible by 8. Sprite images wider than 8 pixels will be parsed as a separate sprite, so you can input a 64x13 pixel sprite sheet and pngParse will output 8 8x13 pixel sprites.



    -s "spritesheet.png"

    Specifies the input spritesheet (required).

    -p "secam.png"

    Specifies the input palette image (ignores the -P flag)

    -o "spriteData.txt"

    Specifies the output file (output.txt by default)


    Uses the PAL palette (NTSC by default)


    Formats output for the DPC kernel (standard kernel formatting by default)


    Formats output for 6502 ASM (batariBasic formatting by default)

  3. To inform everyone, Pinata has been taken out of production. Unfortunately, professional concerns over some of Pinata's content has compelled me to ask Al to discontinue sales.


    I've uploaded the latest version of the ROMs as well as a PDF of the manual to this topic's first post. I kept the 1.0.5 ROMs on the first post as well, in case people prefer playing the pre-cart versions of the games (there were some significant modifications to some of the games).


    Hopefully everyone who wanted a cartridge got one already. Thank you to everyone for your support. :)

    • Like 1

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


    Can you tell which is Stella and which is GameMaker?
    • Like 1

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

  6. 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?

  7. I see a number of potential problems:


    1. The structure of your code is a bit strange. You're declaring the sprite data after it's being used, for instance. That's a bit unusual, though I don't know if it will actually cause problems. Also, you have a clearscreen as the last command, but no drawscreen.


    2. There is no loop. I suspect that things seem to be working only because your game reaches the end of the cartridge, then resets.


    3. You're using two plotsprites, when you really only want one (if I understand correctly). I assume that you're trying to flicker between the joker and a number 7, correct?


    If 3 is correct and that's what you're trying to do, try this instead:

     displaymode 320A
     set doublewide on
     rem **background color...
     rem **set the height of characters and sprites...
     set zoneheight 8
     rem **import the characterset png...
     incgraphic atascii.png 320A 
     rem **set color of 320A text palette 0...
     rem **set the current character set...
     characterset atascii
     rem **set the letters represent each graphic character...
     alphachars ASCII
     dim frame=j
     dim animation=l
     incgraphic seven.png 320A
     incgraphic joker.png 320A 
     plotsprite seven 0 10 11 animation
     goto __Main_Loop



    • Like 2

  8. 2. Yes, you can change the P#C# registers at any time, and the on-screen change happens pretty much immediately.

    Could this be used to simulate the NES's 8 palettes for sprites and 8 palettes for background by drawing the background characters with one set of 8 palettes, then saving the screen, changing the palettes, and drawing sprites after that? Or would the saved screen still reference the new palettes?


    Is the 8-palette limitation as limiting as it sounds like it would be?


    3. Not really, though maybe with some assembly. Yes, you could use plotmap to do coarse scroll , though you'll need to use plotmap each frame, which is expensive cyclewise.

    Is this essentially how scrolling must be done on the 7800, or are there tricky, better ways through Assembly? If so, do those ways conflict with 7800basic in ways that make them less/not viable?


    4. The overlap will increase the number of sprites in the zone.

    So if a sprite is overlapping, it counts as a sprite for both zones?


    8. In theory, 33255.5 cycles per frame. In reality, MARIA puts the 6502 to sleep when it renders the line buffer, and the stolen time varies depending on the display complexity. Also, plotting things takes up a lot of cycles, so the more objects you plot, the more cycles you eat - it's the main reason the multisprite sample maxes out around 24 sprites.

    Wait... So the 7800 can only plot 24 sprites on-screen at a time? What's even the point of it having "greater sprite capabilities" than the NES if the NES can handle 64 sprites on-screen at once and the 7800 clocks out at just 24? Or are you referring to 24 sprites per zone if the zone sizes were 4?


    10. If there's commonly available hardware to support it, in a supercart style format, I can easily add up to 4096k from the software side. I believe the amount of ROM easily supported by MegaCart is 512k, though I may be corrected on that shortly.

    Will this change with batari's 7800 board that he's been working on?




    11. How does one set the background color that is visible when background tiles have a palette color set to transparent? The existence of the background color is mentioned in the documentation (both RT's and the included 7800basic documentation), but I didn't notice any explanation of how it is set.

  9. A few questions:


    1. When a tileset is imported with incgraphic, can the palette, or the ordering of the colors, be changed on the fly during the game's operation (for instance, to create palette swaps of the same sprite/character)? Is there any way to have a separate set of background palettes from sprite palettes, like the NES has, or is the 8 palette limit hardware-based?


    2. Can the colors for a palette be changed on the fly during the game's operation (see above)? If so, are those changes reflected immediately during drawscreen, or does the screen have to be re-written to reflect the changes?


    3. When using sdata, can the pointer be moved in the opposite direction in order to handle a scrolling screen that moves left or right? If not natively, then what about through manipulation of the sdata pointer? Or is that basically unnecessary with the plotmap command?


    4. If I understand correctly, a screen zone is the zone height in pixels, either 8 pixels high or 16 pixels high, correct? So vertically aligning sprites to get a taller sprite should never really affect the number of sprites in a single zone, then. What about if a sprite overlaps the boundary of two zones?


    5. Can the additional ram in a RAM romsize mode be used for sprites or tile definitions that are held in RAM, allowing them to be modified on the fly?


    6. Although tiles in 160A/B modes are 4 pixels wide unless some options are set, what is the width of sprites in that and other modes?


    7. Do RAM-based tile maps take up extra memory of the 1.5K available (or the banks of 16K if using a RAM romsize), or is that memory usage factored into the estimates of 126 variables + 1.5K memory?


    8. How many cycles are actually available for development as compared to batariBasic? I know that the cycles of bB can run out very fast, and I assume that 7800 takes far more cycles as it's doing a lot more complicated stuff. Or is that extra work largely off-loaded to MARIA?


    9. What is the purpose of using tsound instead of setting registers directly? Is there some advantage?


    10. Will ROM sizes higher than 512 eventually be possible?

  10. Very impressive, especially for a first attempt! There really isn't a whole lot of "sacrifice"; the AI has enough intellect to work around the player a bit, the music is active and interesting, the number of options available is impressive, and even the use of the playfield seems fitting and not as ugly as is common with simple games made in batariBasic.


    Great job! Really the only suggestions I'd have would be to add a titlescreen with RevEng's titlescreen kernel for the game selection and to tweak the AI routines a bit. At the moment, you're going over cycles for the playfield title screen and I had one time when the AI thought long enough that I got an unpleasant squeal in my ear from the 2600 going over cycles by so much, so breaking up the AI's thinking between frames a bit more is necessary.

  11. So, on the Intellivision, smooth scrolling is hardware-supported because the on-screen tiles can have a pixel offset of 0-7. For the first 7 frames, the screen is just shifted by a pixel and the tiles are only actually scrolled on the 8th frame.


    Could something similar be done in batariBasic? Essentially, the playfield would need to be delayed based on a variable of 0-3. On the 4th frame, the normal scroll command would be called and the offset would return to 0. This seems very doable, since it's basically just adding a delay to the screen, but then what may seem very simple on the surface is probably pretty complicated when you're racing the beam.


    Any possibility of this? It would be great to have pfpixels smoothly scroll in. It would also likely require a slightly narrower visible screen, as you wouldn't want to see the pfpixels vanishing off the side of the screen and appearing on the other, so some pixels of the pfpixels would have to be masked on the edges.


    For reference, I'm most interested in this with the context of horizontal scrolling, like for a platformer.

  12. Im Sorry Im Having trouble where do I put level2 playfield before titlescreen or after it and before level1 or after level 1?

    Typically, titlescreen logic is separate from level logic, so while it doesn't actually matter, most likely people will go titlescreen->level 1->level 2, etc. for the sake of semantics.


    If you haven't already, I'd recommend reading through RandomTerrain's excellent batariBasic documentation and checking out the examples.

  • Create New...