Jump to content

Mord

Members
  • Content Count

    2,982
  • Joined

  • Last visited

  • Days Won

    2

Mord last won the day on March 7 2010

Mord had the most liked content!

Community Reputation

1,145 Excellent

1 Follower

About Mord

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Interests
    Video games, programming, manga, anime, heavy metal, sonata arctica, blind guardian, assemblage 23, Vocaloid, 7800

Recent Profile Visitors

37,967 profile views
  1. Yes, the general procedure will be the same but you may need to make a few modifications based on if you use 320A or 320B as RevEng mentions above. The original example assumes 160A with double-wide turned on to get 8 pixels per tile. 320A would have 8 pixel tiles without double-wide, or 16 pixel tiles with it. 320B would have 4 pixel tiles without double-wide, or 8 pixel tiles with it. I think 320C would be the same as A, and 320D the same as B but I haven't looked at either very closely.
  2. Yeah, newblock was what I meant - been so long since I've used it myself. Last time I used it for debugging I remember making the newbank typo myself. Regardless it's best to try to avoid using newblock unless you have nothing new to add to the existing block. Using it for debugging odd errors like this can be helpful however! If you use it to sort graphics to different blocks, just remember to remove it when the bank it's trying to closed is completely full of graphics or it'll close off a different block instead and result in odd out of space errors despite having a completely empty block of graphics.
  3. As a test, before the first bolt graphic, try adding a "newbank". This will end the graphics bank prematurely and move those two bolts into the same bank that contains the other bolts. See if the corruption stops with that.
  4. Your title screen loop doesn't have a gosub ReadController, which prevents it from actually checking to see if the player presses a button to start the game. After adding that (To the Rewrite source) the game would at least advance and start - but then it immediately freezes after making a sound. Not entirely sure where it's freezing although you'll probably recognize the sound that's played - use that as a hint to which lines the code is reaching and freezing at some point after it. Could help you trace the code's logic. :)
  5. On line 150 of the source you have "playerY" typoed as "player". That might be causing both of the unreserved keyword errors.
  6. Mord

    Rikki & Vikki

    Essentially you could start up a kickstarter for a homebrew, setting the target fundraising goal to equal the number of copies you want to produce as your minimum number. If you don't get enough people pledging to meet that minimum order then the entire thing fails and nobody gets a copy - at least not directly from the kickstarter. If the number of people who pledged is close enough to what you originally wanted as a minimum then it would be possible to set up a normal pre-order with those people anyway. In effect, you'd know how much interest is actually there for how many copies you would need to produce. If you received a lot more than the minimum number of orders you wanted to do to make it worth the effort you'll at least know how many extra copies you need to produce to satisfy demand. Just because a non-7800 game was used as an example it doesn't mean you can't use it the same way for a 7800 release.
  7. Looks like the source started behaving like the above video as far back as compiled on win64-0.11. When I compile it on 0.10 it works properly, but compiled on 0.11, 0.13, 0.14 and 0.16 you get the glitchy sprites. (didn't try 0.12 or 0.15, but would expect them to behave similarly) 0.11 is where the canary was added and some minor efficiency changes were done for plotsprite, among a few other things.
  8. Keep in mind you can still release games to play on JS7800 or play them normally on Prosystem in general. I just wouldn't use them to playtest code as you're making it or you might end up with a game that won't work on real hardware.
  9. If that's how it looks, then no. It doesn't properly display 320B sprites. Looks like it's displaying similar to prosystem. In that I mean it doesn't follow the rules for the C1 palette entries and gives way too much time for plotting DLs. What version of bupsystem were you using - I'm using 0.9.6.3 and it doesn't show the timer or wave sections at all. You should also see missing bits here and there in the letters, not many but some.
  10. I haven't used JS7800 myself so not sure but if you want to test yourself try running the attached copy of the earliest demo of graze suit alpha from waaaaaay back. In this version the graphics would look corrupted, particularly the player and letters, and you won't see the timer counting down if the rom is being run accurately to hardware. (like A7800/Bupsystem) Back then I use to do all my testing/playing in prosystem so I didn't know about the graphic issues until people pointed it out to me. 2015-05-18-graze.bas.a78
  11. I suppose one way to describe it is that a 320 mode is basically a 160 mode as far as placing sprites are concerned, but each sprite has the fat pixels broken up into two halves with regards to their color. (ie: "pixel pair") In 320B in particular both halves of the pair have conditions for being displayed. Specifically in order for the C1 palette entry to display, it must be paired with a C2 or C3 for the other half of the pair. If you try to have a pair C1's or a C1 + BG, both halves end up being the background color. C2 and C3 can be displayed freely. Also, if you're playing with 320B, make sure you aren't testing in ProSystem. It doesn't understand the palette condition above and will display C1 freely like C2 and C3. Real hardware, A7800, and BupSystem (fairly certain about Bup but haven't tested personally) will display with the rule above.
  12. Not entirely sure about the scrolling you're talking about - basically just sounds like using double buffering. When it comes to trying to scroll two Tiled maps you still end up with problems regarding the wrong palettes being used unless you're updating all the display lists for the new sizes and positions. Which is why I avoided trying to do that for the screen switching in the demo. Making levels with alphachars directly in your source would use a little less space since imported Tiled maps also have an extra table created to quickly determine how the display lists need to be created if I'm reading the .asm files correctly. You won't have that extra table with normal alphachar maps - however that means the map will also be limited to a single palette unless you create your own data structure/table/etc for determining which tiles need what palettes. At that point you're removing the space savings.
  13. Using doublewide for your tiles also extends the size of your potential map since the same map data would cover twice the number of pixels. Another way of increasing the map size would be to "fake it" so to speak. In other words you would have 2 maps in 2 different banks that you would be able to switch between. The second map would start with the same screen data as the end of the first map so that when you switch between the maps the player wouldn't notice anything had happened. You would need to make sure the graphics of each bank were essentially the same except for anything unique that happens in each map - and of course make sure the unique things don't occur during or around that switch over point at the end of the first/start of the second maps.
  14. Certainly possible to come up with other ways of doing it, but I doubt there's any trivial method of doing it with plotmapfiles. Using plotmap to do small scrolling on a plotmapfile will certainly result in errors in the tile's palettes. If your map can make do with one palette it would be easier to just do the larger map and use plotmap. Horizontal scrolling at the very least becomes pretty easy that way. Vertical scrolling however would still be a lot harder going pixel by pixel unless you use the "fake scrolling" method of using black bars to cover up the errors in the bottom zone as you scroll.
  15. It can often be hard to help out with problems like these from descriptions and snippets as the problem itself can potentially be a different part of the code. If you want to zip up what you have and msg it to me I can see if I can figure out where it's going wrong.
×
×
  • Create New...