Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Everything posted by SmittyB

  1. I was inspired to go for the patch and made it, my second after Barnstorming! I played the PAL60 version available on the PlusCart and it might be more obvious on PAL because of the differences in the colour palette, but I noticed that the middle cars tend to be the same colour during the day like how their lights are different at night. With that it makes it easier to stay in the middle where their seem to be fewer cars (until day 4 at least) and then use the colour as an indication of whether to move or not. I found it also helps to think about the accelerator and brake as less about changing your speed and more about controlling how fast the other cars move down the screen. Accelerate so they're moving towards you at a comfortable speed, then go a little faster to push yourself and don't touch the button again except if you touch the side or crash entirely.
  2. The 7800 can be made to draw a bitmap quite easily compared to other consoles and some microcomputers thanks to the way it doesn't have a traditional tilemap+sprites display. Essentially you just draw a couple of wide objects and tell them to get their graphics data from some place in RAM instead of ROM, but the limiting factor is that the 7800 doesn't have much RAM so requires extra on the cartridge. If you look at the graphics in the 3D section there are only ever 4 colours - the background sky, the light brown, dark brown, and the green for the alien guns. All that fits in a single 160A mode palette. As for how the rendering is actually done I can only guess. I think the game takes a semi-randomised grid specifying a height at each vertex, works out how far along the closest gridline a given column of pixels represents, then to draw it it writes to the bitmap with the dark brown colour from the bottom upwards until it hits the height as specified based on the grid and the camera then draws a light bit, then moves onto the section of grid behind it. I think it's basically a low-resolution voxel engine with a lot of interpolation and some controlled randomisation to create the jagged mountains.
  3. As somebody with no nostalgia for the 7800 in my opinion the original library is mostly a bust, but I do find myself going back to some favourites. If I had to narrow down a few highlights I'd suggest these: Alien Brigade - A good Operation Wolf clone, and one of the best games on the system if played with the lightgun in my opinion. Read the manual if you get it because it's easy to shoot the wrong things and find you've lost when you get to the end of a stage. Ballblazer - A fast-paced sports-like game that's good for a few minutes of fun if you can find one that hasn't been (figuratively) melted down for the POKEY chip. Food Fight - As already suggested. I didn't used to understand the hype for it, but it grows on you quickly. Ninja Golf - A very simplistic 'belt scroller' mixed with golf that is strangely appealing despite no single element of its gameplay being better than mediocre. Xenophobe - Basically the same as the 2600 version, just with more colour. Another game that I enjoy playing a few rounds of every now and then. Xevious - My go-to 7800 game when I don't know what else I want to play. I first played the NES version many years ago, but the 7800 version just feels 'right' somehow. There are still a lot of 7800 games that I've not really tried, but of the ones I have played the only thing I'd suggest avoiding unless you can get it cheap is Planet Smashers, the prequel/sequel (depending on the order you play them) to Alien Brigade. It has some good ideas but in my opinion the execution is very much lacking.
  4. They are all winnable, but I just threw them together and added them in the order I came up with them so some are trickier than others.
  5. To nobody's surprise that level bug was another timing issue. I've also made 2 changes based on the stream; firstly you have to press the left button to load the next level after a short delay though I'll be changing how this works later on, and secondly you can hold the right button to speed up the timer or slime at any point. PlumbLuckDX_210905.a78
  6. Eurgh... Another bug that doesn't appear on BupSystem. Using the select switch to skip levels it seems 4, 5, and 6 don't load properly, and level 7 loads except for one set of tiles. I'll work on figuring that one out while I watch the stream I sadly missed. I'm glad you like the title screen; it's one of the things I wished I could have done in the old version, but had to leave it because I just didn't have the time or cartridge space.
  7. Third time's the charm. I've maybe fixed what I think was a bug in the code for resetting the pseudo-random tile limits that under the right circumstances would be put in an infinite loop, but I think the exact behaviour was dependent on whether RAM was zeroed by the emulator / cartridge or not. PlumbLuckDX_210902_02.a78
  8. I've tweaked a couple of things and this build runs on A7800 so should hopefully be fine with everything else. PlumbLuckDX_210902.a78
  9. As long as it works on hardware I won't worry too much for now. That'll be down to those timing problems again and given each emulator is different in how they handle timing, whatever I do still probably cause it to crash on one at least one for now.
  10. Another small update because I'm not sure when I'll be free to work on this over the next couple of weeks. I've found that I'm pushing the limits of frame timings a bit which is why I was getting the yellow screen of death in that earlier build and a few places while making changes to this one. I haven't started optimising the code yet so once I do that it should be more stable. Changes in this build include: Added a brief credit screen. Added fade-ins for the title screen and game screen. Slightly altered the slime graphics on the title screen. There are now 7 levels to go through and they loop once you beat the 7th. The select switch acts as a level skip for testing purposes. The tile selection is no longer completely random, and replaced with a pseudo-random system where tiles will only appear 4 times until every other tile has appeared 4 times too. I might reduce this limit to 3 or 2 depending on testing. PlumbLuckDX_210901.a78
  11. The problem with doing that is as soon as you allow a situation where the 3D graphics are supposed to obscure the things drawn on top you then need to do a lot of masking of graphics in software which then means you need more RAM to hold graphics, and a lot of extra CPU power to do the masking. It would be much more practical to have anything within the 3D space drawn together and then restrict extra objects to overlays.
  12. That was exactly what it was, but it turns out the current build doesn't seem to be affected by it anyway, at least on A7800, so there we go. That trace showed it jumping out of the middle of that routine unexpectedly so perhaps an interrupt was firing off at an inconvenient time or something. As well as somehow fixing that bug, this build has slowed down background animations, an improved transition from the title screen, better sound in level transitions, fixed a minor issue where tiles would subtly flash when slime moves into them, and the level counter now works. I'm working on the map format and I think I've come up with something flexible enough to get a good number in before potentially changing to random maps. The format I'm thinking of can place individual tiles at 3 bytes per 2 tiles and runs of up to 16 of the same tile using 2 bytes with a 255 value marking the ends of each list. PlumbLuckDX_210826.a78
  13. Thanks @RevEng, that trace looks like the code to scroll the background so I'll start my troubleshooting around where it's first called. It's interesting that it doesn't appear to affect PAL hardware or 3 out of the 4 emulators I've tried it on which I'd expect something like this to do.
  14. Thanks all for the kind words. I played a lot of the Windows 3 version of Pipe Dream back in the day which is why I have the grey and green colour scheme over the more colourful Amiga original Pipe Mania. I put my own spin on it by requiring you to reach a drain tile rather than just having a pipe of a given length, but unbeknownst to me at the time there was a Pipe Dream arcade game that did the same thing. The NES Pipe Dream has 8 frames of animation per tile like my previous version of Plumb Luck so while I don't have special tiles it is a little smoother looking. In due course. I'm going to finish that damned game if it's the last thing I do. I have halved the animation speed which I think does make it look a little better and not too choppy. Thanks, I'm especially pleased with how the cursor turned out given that transparency is disabled. For those who haven't been following my ramblings on Discord - As the 320 modes don't have fully working transparency I'm building the cursor graphics in RAM like a software sprite in a ZX Spectrum game by taking a copy of the graphics the cursor is over, masking them out with a bitwise AND (lowest row of the image), then adding the cursor graphics with a bitwise OR (middle row), resulting in the graphics I want (top row). By swapping out the mask and graphic every few frames I can animate it without needing to do anything fancy. I've noticed that and I'm not sure what's causing it. I'm mainly using BupSystem to test because it highlights bad timings more than A7800 and it works fine in that, plus it works in A7800 when running PAL, and it works on my PAL hardware. I suspect there's some timing issue, so if somebody can test on NTSC hardware then I'll know which emulator to believe.
  15. "This is it. You've landed the biggest contract you've ever seen and you're going to need it if your small plumbing business is to survive. What you didn't know before you signed however is that many others have been hired and fired during the construction of this toxic waste facility so you'll need to contend with their leftover piping, and to make matters worse the pumps will be turned on today whether the work is finished or not. Delays are unacceptable! If you're going to complete what was started, claim your payment, and avoid an environmental disaster, it's going to take all of your skills, quick thinking, and sheer plumb luck!" Plumb Luck DX is a follow-up to / remake of the second (first finished) of my 7800 projects Plumb Luck from 2017. In a way it's really the game I wanted to make back then but couldn't because I wasn't anywhere near as familiar with the system as I am now, and this is why in game it's only called Plumb Luck rather than Plumb Luck DX. It exclusively uses the 320B mode for high-res graphics, and extra RAM on the cart to allow for far more frames of animation than would be possible without. The aim of the game is to prevent the toxic slime from spilling by placing pipes to create a path from the pump to the drain. It's not as simple as it sounds though as you won't always get the pipes you want, the path the drain won't always be clear, and you'll want to build the longest path you can for the most points. This 22nd August build is fairly bare bones, but I wanted to have something posted while I work on the rest of it. At present there is only a single empty level which repeats when winning or losing, the level counter just shows a debug value of the tile number, and the score counter does nothing. The title screen graphics will eventually be given a layer of polish, I should be able to fit some extra background graphics in (I'm already pushing the graphics limit of a 128K cartridge thanks to the 320B format), and I'll throw in a few AtariVox phrases where I can because you can never go wrong with more AtariVox support. There's a bug I'm aware of where corner pieces won't work properly on the left or right walls as it will count the slime as having hit the wall rather than been redirected up or down. Try on JS7800 PlumbLuckDX_210822.a78 (NTSC colours only for the moment)
  16. I don't have a good example of the scrolling plane effect as it looks like I didn't post the build that screenshot is from which made it run a lot better and fixed some of the perspective issues, but here's the closest. The biggest problem with either of these effects on the 7800 is that you have to waste a lot of CPU time counting the lines being drawn on the screen like a 2600 game in order to change the colours in the right places. I just hardcode the map data in my builder and then recompile it to get the output so this is what it is currently in my test build. As the comment suggests you give it the distance from the current height to the target height and the base colour it should use. It then runs through a bunch of steps to interpolate through the points to create smooth transitions, and then crudely adds shadows by adjusting the colours where the height is lower a shadow cast by a given point. double initialData[][3]= { //X steps to get Y height with Z colour {2,128,0xD3}, {32,80,0xD3}, {32,64,0xD3}, {32,100,0xD3}, {6,120,0x13}, {40,80,0xD3}, {4,90,0xD3}, {40,0,0xD3}, //River {40,24,0xD3}, {4,16,0xD3}, {4,0,0x13}, {1,0,0x97}, {16,0,0x93}, {1,0,0x97}, {4,16,0x13}, {16,16,0xD3}, {3,10,0x13}, {16,0,0xB3}, {16,32,0xB3}, {32,72,0xB3}, {4,64,0xB3}, {50,128,0xB3}, {3,124,0x13}, {16,100,0xD3}, {16,80,0xD3}, {16,70,0xD3}, {32,128,0xD3}, {32,128,0xD3}, //Wall {1,129,0x13}, {1,135,0x07}, {1,140,0x08}, {1,145,0x09}, {1,129,0x13}, {1,128,0xD3}, {50,128,0xD3}, //Road {5,132,0xD3}, {2,120,0x13}, {6,120,0x07}, {2,122,0x13}, {2,122,0xD3}, {2,120,0x13}, {6,120,0x07}, {2,132,0x13}, {5,128,0xD3}, {2048,128,0xD3} };
  17. See for yourself. Though it doesn't really show it off nicely in that build which is something I was working on, that's a 1D voxel heightmap drawn using only the background colour. It runs better on PAL thanks to the extra VBlank time, or if the draw distance is reduced a bit in the source code. The biggest limitation to making it look good is a decent map editor. I've got a quick and dirty program that lets me build maps without having to manually enter thousands of values, but it's not easy to get good results.
  18. The way the roads work in Motor Psycho and similar games is something I've also dabbled with on the 7800. It's not truly 3D but it's a good way to simulate a 3D space. I used a simplified version of this technique in older builds of Spire of the Ancients before I was able to get the voxel heightmaps working. It's not easy to see from the screenshot but the floor pattern is a texture that goes off into the distance and is able to scroll forward and backward like a plane in a 3D space. What this really is the below texture (rendered in Deluxe Paint 3 on my Amiga) where each colour represents a different colour in a palette. By changing the colours in the different positions in the palette on as it's drawn down the screen I can create the effect of a scrolling texture; that's how games like Pole Position handle the moving road markings. Though not something I did, by shifting lines left or right by different amounts you can create curves, and by skipping or duplicating lines you can create hills and valleys.
  19. You might be thinking of Spire of the Ancients, in which case I'm the developer and it's one of the reasons I wouldn't want to start a 3D project right now. It's been on hold for a bit so I could get some smaller projects under my belt (SotA is the first thing I started on the 7800), and because it's outgrown my Mateos cart so I needed to wait until I could get a Dragonfly which I now have.
  20. In the sense of answering questions where I can and making suggestions, yes. Whoever codes it would need to know assembly as at a minimum the drawing routines in 7800basic aren't set up to allow you to point to arbitrary spots in memory for the graphics, but with assembly you can manually set up those routines to do so. Additionally as good as 7800basic is, with the amount of data to be shifted it would be noticeably slower from small overheads than handwritten, optimised assembly.
  21. @Giles N I do, but I have too much on my plate with other projects to get into it. I'd be more than happy to help in a small way if anyone wanted to try it. Personally I would aim for a 256*192 resolution using the 320A mode for wireframe graphics as it would take only 12 objects to set up the entire 3D display, and HUD elements could be drawn in the 32 pixels either side if needed (or overlaid keeping in mind the transparency limitations in 320 modes). The 320A mode also simplifies the rendering because you don't have to worry about managing pairs of bits to get the right colours, nor would you have to take into account the wide pixels for screen coordinates. A screen's worth of graphics data (32 bytes * 192 lines) would be exactly 6K so cart RAM would be necessary, but it would be possible to double-buffer the screen and have 4K left over for game data.
  22. To me that poster looks like it was put together by somebody who had flicked through the 7800basic documentation and never used it or actually understood it. The abstract lists the limitations of 48k ROM and 4k RAM. It's true the 7800 can address 48k through the cartridge port, and the stock system has 4k RAM, but that 48k can be anything including extra RAM and bankswitching removes any real space limitations. This looks like it was copied from the 7800 Wikipedia summary as 7800basic has supported the 128k+RAM format for as long as I can remember (not forgetting all of the original releases that used it). The images are grabbed from the 7800basic samples and seem to just be used to fill space. There is no context for why the ATASCII characterset has been included because it's not relevant to the subject at hand. The worst part for me is the complete ignorance about the 7800's major strength; "7800basic displays images only through 8*8 pixel sprites". Technically the 7800 doesn't have sprites, but I can overlook the use of common terminology to get the message across, however the 7800 (and 7800basic) display objects 32 bytes wide and one zone high, which in the most common configuration is 128*16. If this paper is actually real then it can't be trusted anyway with such blatant errors on the first page. I think it's safe for me to say that I've done more with 3D on the 7800 than those 3, having written a voxel heightmap renderer for the title screen of Spire of the Ancients, and having set up a bitmap where I can adjust arbitrary pixels in the title screen for Plink.
  23. Graphically the C64 and 7800 are similar enough that a port would make sense. I've only seen screenshots but it looks like the C64 version has a slightly larger view vertically which would affect the framerate, but more importantly the C64s bitmap mode would mean either the game uses sprites for the background, or it's extra work for the CPU to clear it and redraw it each frame.
  24. The problem is that the bit you'd want learn is mainly the drawing algorithms and those are almost always heavily optimised to the hardware. The best things to learn from would be games on systems with similar CPUs and graphics structures. Fortunately the 7800 is flexible enough to set up a straightforward bitmap display even if the underlying hardware isn't built for it.
  25. I mean arbitrary angles aren't possible. You're never able to move the camera in such a way that the polygons aren't perfectly horizontal or vertical.
  • Create New...