Jump to content

SmittyB

+AtariAge Subscriber
  • Content Count

    583
  • Joined

  • Last visited

Community Reputation

1,140 Excellent

About SmittyB

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male

Recent Profile Visitors

8,125 profile views
  1. That's a good idea but I'll have to see how much space I have left once I've got all the sound effects, music, and voice that I want. As each door is actually 2 objects some are already unlocked to allow backtracking, but of course as it stands you'd then have to unlocked the door to go the other way. I've also colour-coded doors and portcullises that are permanently locked so it's more obvious when a path is a way forward or just decoration.
  2. I've rearranged my RAM, found plenty free, and have done exactly this. Now when you collect a key or unlock a door it stays collected or unlocked until you die or otherwise go back to the title screen. There's no way to save it because I'm already using all 25 bytes allowed for HSC/SaveKey and the passwords are already 50 characters long, anything more would be far too much.
  3. Rand returns the next in a fixed (but very long) sequence of arbitrary numbers. Where it starts in that sequence is determined by the seed value, but there's no guarantee that the seed value will be different each time. If you call rand each frame and ignore the result you'll get a seemingly more randomised sequence because the arbitrary number of frames between when you actually need to use a random number makes the whole thing unpredictable.
  4. That's correct. An easy way to convert between the two is to think that NTSC colours are a row higher (or vice versa) so #$34 on PAL would be closest to #$24 on NTSC. The greyscale range at #$0x being the exception.
  5. At this point it seems it would be better if ProSystem quietly disappeared from the internet because it's just not up to the standards of other emulators and from what I've heard includes a number of bodge fixes to get even the original retail releases working properly. JS7800 is based on it but doesn't have a lot of the same problems fortunately. A7800 and BupSystem are as good as hardware for almost everything so you can't go wrong developing with those. As for the graphics, most early systems' graphical prowess was in how they could draw tilemaps and / or bitmaps to the screen with fancier systems capable of shifting the tilemaps in pixel increments, flipping tiles around, or having different palettes in different locations, but the sprite capabilities were always relatively lacking. The NES and Master System both have a fixed amount of memory to manage 64 8*8 or 8*16 sprites but can only draw 8 on a given line, while the C64 has 8 24*21 sprites (12*21 in multicolor mode similar to 160A on the 7800), but the 7800 goes completely the other way by dropping the tilemap and making everything that gets drawn a sprite (sprite isn't the best term but it's what most people think of them as) so it can draw sprites up to 248*16 (124*16 in 160A mode and that's if my maths is right). Of course this allows for huge graphics on screen that other systems can't do without plenty of trickery, but the downsides, of which there are many, include that while the objects can be placed anywhere horizontally they must be aligned vertically to a zone so scrolling vertically requires a lot of fiddling about and horizontally requires moving every object instead of just updating a shift register, and as each object is drawn with a single palette you need to have multiple objects if you want more than 4 colours in your pseudo-tilemap built from 'indirect mode' objects. As each object to be drawn requires the system to read a header to understand what it needs to do, and 'indirect mode' objects require extra processing to read the tilemap, one of the ways to optimise things is to ditch the mindset of tiles, make use of the 7800's strengths, and just have bits of your levels just be single large chunks of graphics. With all that said, 7800BASIC takes care of a lot of the details so you don't need to worry about them until you get into more advanced stuff and you shouldn't focus on optimisation while you're learning the ropes as @bizarrostormy suggests.
  6. That does look fun, I'm eager to see how it develops. For my answers I'm going to assume you're using 7800BASIC. When you import graphics from an image 7800BASIC doesn't know what colours are used, rather it sees that some of the pixels use the first colour of the palette, some the second, and so on. Almost no graphics editors let you specify which colour is in which index so when you draw different frames for your characters there's no guarantee that the same colours will be in the same places. To get around this you can swap around the indices that the graphics are mapped when imported as part of the inc- statements. I believe you can also include an extra row under your graphics with the colours in a particular order to do this though I've not tried it myself. The sample graphics show this. If you're using 'plotmap' that will only draw using the palette set in the parameters. If you're using 'plotmapfile' that will essentially plot multiple maps each with a separate palette and it knows which palette to use by a parameter in the incgraphic statement. The idea is that you import a tileset for one palette, and another tileset for another palette, etc, then when it draws a tile in that range it knows to do it with the right colours. Though it wouldn't be a problem in your example you should be aware to avoid situations where the palette needs changing several times on a line because in the background it does this with multiple objects and you can quickly hit the limit of objects per zone. This could be a couple of things, but all I know to advise is to make sure you pad out even small graphics to be the height of your zone size, and maybe try changing the order of how things are imported. I believe it might be related to the bit below mentioned on the guide.
  7. There's another way to do it with indirect graphics and that's by using a separate object drawn on top to slide over the tiles and then change the tiles when it moves far enough. For example if your meter was at 29 of pixels 64 you'd have 3 tiles (assuming 8*8) covering 0 to 24, and then you'd have a second 8*8 object overlapping it that covers pixels 21 to 29. To have values less than 8 it would then need to be masked on the left with another object on top of that, preferably something that would already be drawn in that spot. I'm not describing it very well but if you look at the growing vines or the moving block platforms in a couple of the castle levels of Super Mario World you'll see what I mean.
  8. It might not recognise the command because it's only imported when a couple of conditions are met. Firstly you need to use the command "set hssupport $1234" replacing the number with a unique identifier of your choosing, secondly you need "incgraphic hiscorefont.png 320A". If you set hssupport without including a hiscorefont graphic it'll import the routines for loading and saving data but it'll leave out the stuff to show the high score tables.
  9. Thank you for the kind words. I'll get there eventually, 4 years on and still technically my first 7800 project.
  10. Nothing is drawn twice that shouldn't be in practice, but there are several branches of code that will reference and draw things in the same spots based on different results from previous checks. Some of the labels / comments are probably inconsistent depending on how I was thinking about the map at the time.
  11. Not in the sense of full of water. I wanted to but dropped the idea very early due to various constraints. Catacomb 3D has a couple of water levels that were what I was going for. I think I could still do it but it'll be more hassle than it's worth. I probably won't add any lower levels to the flooded tunnels as they're mainly a path back to the underground area which will be the third main area after the graveyard and garden labyrinth and that will have more verticality in its layout.
  12. I've cracked it and it's all working now. It just took a copious amount of irn bru and Iron Maiden to get through. It's funny, it almost doesn't feel different because I'm familiar with the maps but at the same time it feels a lot better to play. I've already found one spot where being able to see further made a map transition visible so I'll need to watch out for that going forward. In case anyone is curious, here's the hefty chunk of code that resulted. I'll tidy up the parts where I'm making checks and then clearing the same bits of tilemap either side of the branch for the sake of saving some ROM, but I think it's about as efficient as it can be which is nice.
  13. I've gone back over this a few times already and I'm having a hard time figuring out what needs drawing and when to cover all combinations of walls that should be visible.
  14. Getting there. Now I need to make it draw the sides properly when you're not next to the wall you're facing, then it'll be a case of making it actually check if there are more paths on the far sides as at the moment the far side walls are just forced as walls. This is going to let you see way more of the map at a time at the expense of objects appearing to pop in when going around the corners, but I think that's a good trade-off.
  15. switchselect, switchreset, switchleftb, and switchrightb aren't routines that you define like topscreenroutine or pauseroutine, rather they return a value that when used in an IF statements acts like a true or false answer. The below example checks if the left difficulty switch is set to A by saying "if not switchleftb". If you wanted to check that it's set to B you'd just take out the 'not' (!). The other switches work the same way. if !switchleftb then goto skipSetMusic thisbank
×
×
  • Create New...