Cybearg
-
Posts
951 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Cybearg
-
-
Is that similar to the Graphics Converter that VbB has?
... God dammit! How did I never notice that existed?!
-
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.
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)
-
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.
-
1
-
-
Just do a pallet/graphics swap and make the protagonist a girl, Call it Lore of Zenia or something.
And if you make the protagonist look a lot like Zelda, you may even get the FemFreq shout-out.
-
Top one is Stella.
Mhm. Still, close enough for prototyping purposes, IMO.
-
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:
................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX......................XXXXXXXXX........................XXXXXXX.............................XXX...XX.XX.....................XXX.............................XXX...XX.XX.....................XXX.............................XXX.............................XXX........XXXXXXXXXXXXXXXXXXXXXXXX.......XXX................XXXXXX......XXX.................XXXXXX.....XXX..................XXXXXX....XXX...................XXX........XXX......XX.XX.XXX...XXX.........XXX...........XXX...XXX..........XXX....XX.XX.XXX...XXX...........XXX.........XXX...XXX............XXX........XXX...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Can you tell which is Stella and which is GameMaker?-
1
-
-
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.
-
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?
-
Well, I have 4 more projects I'm going to do for the Atari 2600. After them... jumping over too the 7800...
^-- What I keep saying.
-
Do these maps actually take up the whole of those 256kb, or did you pick 256kb just as an arbitrary choice?
-
Out of curiosity, was this done with 7800basic or ASM?
-
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
-
2
-
-
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.
-
I don't expect a lot from people's first efforts...
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.
-
Awesome! Thanks for the update!
Other stuff previously discussed in the thread - scrolling, vertical resolution, etc. - is still in the TO DO queue.
Are you finding more time to work on things again?
-
Will this result in a marked decrease in available CPU cycles, memory, etc.?
-
Are new High Score Cartridges being produced, or is this just for the lucky folks who bought one when they were in production?
Is this a superior solution to using an AtariVox?
-
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?2. Yes, you can change the P#C# registers at any time, and the on-screen change happens pretty much immediately.
Is the 8-palette limitation as limiting as it sounds like it would be?
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?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.
So if a sprite is overlapping, it counts as a sprite for both zones?4. The overlap will increase the number of sprites in the zone.
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?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.
Will this change with batari's 7800 board that he's been working on?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.
Also:
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.
-
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?
-
I own every game... potentially.
(I have a Harmony cart with a 4Gb SD card.)
-
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.
-
The simple answer is no.
What if the playable screen area was narrowed, giving more time to set up the shift between scanlines?
-
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.
-
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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Adventure Demo - 7800basic
in Atari 7800 Programming
Posted
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)?