-
Posts
861 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by SmittyB
-
@Jasonhrb I think that's about the best description of the state of things in the UK during that time and "[...] there are people who actually suggest that a main period of popularity for the 8 bit consoles was actually as a budget alternative to the 16 bit consoles after the latter were established." is certainly correct from my experience. I think the turning point for the UK was 1990. 1990 is when Nintendo took over distribution of the NES from Mattel and dropped the price to £100 to match its competitors, the combination of which made it more available to the average family. By that time the surviving microcomputers like the Spectrum and C64 had also dropped heavily in price, with the added benefit of many years of market support with hardware, software, and books in every shop. The Master System also already had a decent userbase because while it was more expensive than the microcomputers it was cheap for a console and was sort of the deluxe way to play games for those with the money, so by 1990 when it was being wrapped up in the US it gained a new lease of life as it became available to the people who were jealous of their well-off friends who had one. On the 16-bit side the SNES was still 2 years away which was just as well seeing as the NES was only just getting a foothold. The Amiga had of course been available for years but wasn't really seen as worth investing in until the famous Amiga 500 'Batman pack' bundle was released for only £400... compared to the Megadrive's release price of £190 which was still about twice the price of the 8-bits. I see it a bit like the availability of the internet. Sure it was around for ages, and there were plenty of people who got in early, but the mass appeal came way later than people tend to think.
-
I would like to reserve $2822 for Plumb Luck DX please.
-
I don't use plotmapfile much so I don't have any definite answers, but I did notice a couple of things. Firstly in your maps you have tiles that aren't explicitly defined so that they're listed as '<tile/>' rather than for example '<tile gid="1"/>' and presumably 7800basic interprets these as zeroes but it may be best to specify. Secondly, in your plotmapfile call you're telling it to read the tile data from 'currentmapdata' instead of 'forest_20x14_screen2' so unless you're copying the tile map across at some point I believe it'll use whatever tiles are set at currentmapdata while splitting the objects and palettes based on the contents of the TMX file.
-
Nicely done! I remember doing the same when I started and still have the files. I played around with changing the tile map and shifting things left and right with the controller before deciding that I'd just learn 7800basic, heh.
-
Glad you like the cursor, it seems to be a winner this time. I'll likely add extra frames of animation to smooth it out as it skips in a couple of place. The GB version of Pipe Dream adds a multiplier for all tiles within a loop, but that's too complicated for the way I'm doing things so I was deciding whether to include a large bonus for using a crossover or adding a multiplier, but I like the idea of somebody being able to rack up huge points by planning out complicated loops. I think playtesting will be needed to make sure we don't end up with everyone maxing out the score. At the moment losing a level means you just lose a few points and the level select doesn't automatically move to the next one, but I'm currently planning to make it so that you can build score across multiple levels but as soon as you lose once it resets to zero and if it's a high score it's recorded. Players who want to go for high scores need to beat successive levels in one go whereas players who just want to see every level can have as many attempts as they want.
-
I've done a lot of work on this since the last posted build though a lot of that didn't get results, however what's here is getting closer to something I'm happy with. There are a few things that need polishing and there's still more to do, but this should be a much better build than previous ones. Try on JS7800 I tried adding dithering to the shadows, but that meant MARIA would have to draw just a little bit more than it could handle. To counter that I tried drawing the cursor as part of the tile map instead of an extra object which would have plenty of other benefits, but it caused too many problems with the logic to create the cursor graphics for me to fix. In the end I decided that it just wasn't worth it. The below mock-up is kind of what I was going for. Along similar lines I was working on improving the 'next tile' list but smooth-scrolling and / or dithered shading was just too much to process so I've added a quick sliding animation just on a tile-by-tile basis. As for changes that did make it in I've updated the graphics on the title screen somewhat. It's closer to what I initially imagined with an attempt at more of a pseudo 3d looking slime. I had to remove the bit where the slime raises in the transition to the game screen. I've finally managed to add in a crossover piece which has been on my to-do list since the original Plumb Luck. As you can enter a crossover piece from any one of four directions and then again from one of two directions there are a a total of 8 combinations, each of which have 16 frames of animation so that's already as many tiles in the original so this wouldn't be doable without holding the graphics data in RAM. There's now a 'tile goal' counter marked T which is the minimum number of tiles you need to place in addition to reaching the end tile for the level with the idea being that players are encouraged to do more than take the shortest route to the exit. At the moment these are set low until they can be balanced. Additionally, if you try to place a tile over an existing tile there's a longer delay compared to placing one in an empty space so that it's less effective to just hold the button down until the right tile comes up. PlumbLuckDX_220327.a78
-
WSYNC (Wait for Sync) is something inherited from the 2600. Writing to WSYNC halts the CPU until the beginning of the HBlank period between visible lines of the display. That means you can force the system to wait a number of lines for some basic 2600-like raster effects, but the downside is that you're wasting CPU time just counting lines.
-
Bankswitching backgrounds & drawwait
SmittyB replied to BydoEmpire's topic in Atari 7800 Programming
The drawscreen command finishes at near the top of the visible screen rather than the bottom meaning with the code you posted it would jump into bank 2, wait for the end of the visible display to run restorescreen, run your drawing subroutines, then wait until the start of the visible screen, at which point it then returns back to bank 1 before going through the motions and going back to bank 2 and waiting for restorescreen. Essentially with that setup the more logic you have in bank 1 the longer it takes to get back to bank 2 where your graphics are. Of course having a drawscreen command in bank 2 to wait around while the screen draws is one way to solve the problem as you found, but it also means wasting a lot of CPU time. Hopping back and forth between banks actually requires a small bit of setup that can easily add up as well so this looks like the kind of situation where you would be best off duplicating your code into each of your banks to do as much as you can without leaving the bank your graphics are in. -
Using SaveKey for save points for longer 7800 games?
SmittyB replied to Pac-Lander's topic in Atari 7800
Trebor beat me to it. As for save points, I use it for that in Spire of the Ancients (though there are only a handful of spots to save in the available builds). 7800basic lets you easily save 25 bytes of data and I use all 25 bytes for various things including a checkpoint ID, and then from that ID I can get the map, location within the map, and direction the player should be facing when the game loads. I'm kind of assuming people with play Spire of the Ancients with an AtariVox / Savekey, but I've included a 50 character password for those without (and the values are scrambled so it's harder to cheat). -
Thanks @RevEng. My quick and dirty animation is a little choppy but it looks passable at the moment and in motion nothing is obscured.
-
For those wanting a different cursor I've added an X shaped one but I don't know if it's any better than the previous one. Any thoughts?
-
That's why I mentioned the speed, and the amount of RAM isn't an issue because a 256*192 bitmap is only 6K, so with 16K cart RAM that leaves plenty of space. The point of my old mockup was to see what something would look like using just a background layer and objects on top so I'm not saying it can't be done, just that everything has to be designed so that things can't go 'behind' the background whereas with bitmapping that's not necessarily an issue.
- 13 replies
-
- 1
-
Having isometric (or dimetric as the case may be) games on the 7800 is something I've given a fair bit of thought about. Regardless of whether you go with tiled graphics or bitmaps the tricky bit is obscuring graphics where appropriate. As soon as you allow the possibility for something to be drawn in front of or behind something else based on its position you need a way of hiding the thing that's supposed to be behind it which isn't always possible. In the below mockup I made years ago you can see there's no spot on the map where one of the people could stand behind part of the level (except for that one guy in the top middle, but it would be easy to stop him walking 'behind' the walls with generous collision checks). If someone were allowed to wander around in the purple area and walk under the bridge there would need to be a way to selectively chop bits off of the graphics which just wouldn't be feasible without bitmapping. Providing speed isn't a requirement, the way I'd do it is bitmap the screen as either 320A or 160A. It would be possible to draw the static elements of the screen and then have the dynamic parts keep track of what they're overwriting each frame (to avoid redrawing the entire screen), or have a copy of the entire background and just restore from that which, while having more of an upfront RAM and speed penalty would make memory management easier, and you can just restore the screen in one go instead of walking back through each object to restore what it overwrote. There wouldn't be a reason why objects couldn't be drawn on top of the bitmap but read their graphics from it in order to have different colour palettes (albeit with a bit of spectrum-like colour clash depending on how it's done).
- 13 replies
-
- 2
-
320B would definitely be doable with kangaroo mode enabled for 4 hi-res colours. In terms of drawing it would essentially be equivalent to 160A but with modified masks as the bits are in a different order. The tricky bit is that while 160A and 320B are both 2bpp modes, with 160A's wide pixels it takes up the same screen space as 320A whereas 320B is drawn half as wide. That means unless you're happy with a 160 pixel wide bitmap you need an extra DL entry per zone, double the memory to hold the bitmap, and double the processing power to draw something the same visible size.
-
I've made the adjustments to the 160A drawing and have adjusted the 320A drawing with similar logic. Rather than using EOR to erase the lines by drawing over them again, you specifically choose the colour and it will draw in that colour. That gives much better results when lots of drawing is happening in a small space such as the middle of the circle. On this updated ROM you can press select to switch between the 320A and 160A loops. JS7800 BitmapTemplateV2_220123.a78 BitmapTemplate.bas
-
There are a few things I overlooked with 160A but nothing that's not easy to work around. There're a lot of things to tweak to get it perfect but as a proof of concept it shows that 160A bitmaps are easily doable.
-
Not a medal, but maybe you'd be in the running for the annual Atari Homebrew Awards
-
Or one could produce a wholly original game along the same lines that takes full advantage of the system's strengths. *cough* ?
- 19 replies
-
- 10
-
Another nice advantage of that mirror mode is that you can then bitmap with the 160 modes and get square pixels which might look better in some circumstances. Speaking of 160A, it should be fairly simple to modify the code as it relates to getting the bitmask to allow for 4 colours. You could adjust the offset into the table so that the first set of entries are the offsets for colour zero, the next for colour one, etc. You could even have it so that adjacent x coordinates write to the same pixel as a sort of free sub-pixel accuracy, and you wouldn't need to account for the ratio difference between x and y elsewhere in the program. A lovely side-effect of the 7800's wide pixels is that a 160A bitmap would have the same footprint in memory as a 320A one so you don't need to have separate lookup tables for each version relating to how the lines are arranged. I might have a play around with those ideas and see how things go.
-
No it doesn't. Essentially the 7800's strength is in drawing large sprites, so I'm filling the screen with rows of sprites and telling the system that their graphics data can be found in RAM rather than ROM, then as long as I write to that area of RAM in the correct order I can put a dot anywhere within the bounds of those sprites. With the ability to put a dot on the screen that then opens up the ability to plot the points of a line (though there are more efficient ways than drawing it point by point), and once it's possible to draw lines then it's possible to draw shapes including maybe wireframe 3d which I would love to see. This 256x192 bitmap takes 6k to store, so in a typical 128k + 16k RAM cartridge it would be possible to double buffer the screen and have 4k plus the system RAM left over. If one were quick enough, it would also be possible to bankswitch RAM while in vblank to process the game state before switching back to do the drawing.
-
Having experimented with a bitmapped 320A display in Plink I've been thinking of the possibilities that allows, and so I've also been experimenting with line drawing. I've put together some example code that can be used as a starting point for anyone interested. BitmapTemplate.bas BitmapTemplate.a78
- 17 replies
-
- 12
-
@Propane13 I think I get what you're suggesting, but if I am then it wouldn't work with kangaroo mode on as holey DMA makes MARIA see zeroes in certain ranges, but those zeroes would be interpreted as solid black and so only the last object drawn would be visible in the zone. You have given me an idea though so thanks.
-
While the 320 modes can have transparency which I made use of that in Plink to mix colours in 320A, with 320B you then run into the problem of certain pixel combinations being drawn as background colour (in this case black) so if I disable kangaroo mode it just looks like the below screenshot. Maybe I can rearrange the palette and adjust the graphics to make it work, but I don't know, and having that restriction would be annoying if I wanted to change something.
-
Glad you like it. What you mentioned are all things I've thought about and do intend to do more work on, but there are limitations that make it tricky. I'm using 320B mode so I only have 2 palettes of 3 colours + background and no transparency (without mid-screen changes). 1. I've considered having a gradient effect to emphasise the top of the screen and / or have the tiles slide up (mock up below), but as I don't have transparency I can't just draw the tiles as separate objects and move them around, nor can I overlay the gradient on top of the existing graphics. It's doable, but in order to do so I need to build up those graphics in RAM like I do for the cursor, background, and slime. It takes a fair amount of time to process that and I don't want slowdown for the frames on which it's updating. I'll need to see what I have space for towards the end as I'm also going to look at adding crossover pieces like Pipe Mania, but the way they work would be an exception to just about every bit of logic in place at the moment. 2. It's not something I have any trouble with personally, but a couple of people have mentioned the cursor being too chunky so I'll look into it. With the lack of transparency the cursor has to be the same colour as the tiles under it, and making it larger than 16*16 would add to the complexity of building the graphics as I'd need to read the surrounding tiles and copy their graphics as well. I could maybe make the cursor thinner or make it an X, but let me know if you have any ideas. 3. This is on the to-do list. Rather than a grey and green explosion I'll be doing a dissolve effect like the blocks in Plink.
-
I've always thought Capcom should have continued the naming pattern for the sequels; Ghosts 'n' Goblins Ghouls 'n' Ghosts Grotesques 'n' Ghouls Gremlins 'n' Grotesques Grindylows 'n' Gremlins etc