Jump to content

Cybearg

Members
  • Posts

    951
  • Joined

  • Last visited

Recent Profile Visitors

9,102 profile views

Cybearg's Achievements

Dragonstomper

Dragonstomper (6/9)

147

Reputation

  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. ... God dammit! How did I never notice that existed?!
  3. 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. bBpP_1.0.0.zip 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. Flags: -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) -P Uses the PAL palette (NTSC by default) -D Formats output for the DPC kernel (standard kernel formatting by default) -A Formats output for 6502 ASM (batariBasic formatting by default)
  4. 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.
  5. And if you make the protagonist look a lot like Zelda, you may even get the FemFreq shout-out.
  6. Mhm. Still, close enough for prototyping purposes, IMO.
  7. 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?
  8. 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.
  9. Would you recommend making the game in 7800basic from the start, or prototyping in something else, like GameMaker?
  10. Do these maps actually take up the whole of those 256kb, or did you pick 256kb just as an arbitrary choice?
  11. Out of curiosity, was this done with 7800basic or ASM?
  12. 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... BACKGRND=$12 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... P0C2=$0F 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 __Main_Loop clearscreen frame=frame+1 animation=(frame/16)&1 plotsprite seven 0 10 11 animation drawscreen goto __Main_Loop slots.bas slots.bas.a78
  13. Pickle, keep in mind that when we say "high level," that is relatively speaking. BASIC and C is as high-level as you're going to get, and both come with limitations and make less efficient code than programming in raw Assembly. There is no object-oriented Lua equivalents. You're going to be using global variables and GOTOs.
  14. But those second efforts better be the most amazing thing ever put to ROM or else you will forever earn Rev's disdain and deep-seated personal disappointment.
×
×
  • Create New...