Mord
-
Content Count
2,986 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Mord
-
-
8 hours ago, Rick Dangerous said:Yep, we all know digital sucks. That's why I'm not buying any more consoles, just sticking to PC at this point.
Yeah, I'm probably in the same boat although I don't know if I'll be buying much more on PC than I already do (which is mostly things that hit critical sales levels which still happens on PC from time to time compared to consoles)
I'm probably more likely to regress into older consoles more and buy up things from PS2 and earlier - before the DLC plague began.
I looked at the PS5 and I really don't see any desire to get it. Kind of the same feeling I had for the PS4 although still gave that one a chance to prove itself. While there were some good games on it I still don't feel like it's justified it's purchase. (And Xbox is dead to me already, so getting their new console isn't even on the table.) The general unavailability of buying either of the consoles at present, even now due to scalpers, is also a consideration but a far second to the fact that I'm just not interested in either of them nor the games available on them. I do have interest currently in the Switch, but given that I play that rarely as well means it might be my last handheld/console as well except potentially a backwards compatible HD upgrade Switch.
-
1
-
-
On 3/23/2021 at 3:03 AM, 0078265317 said:Probably a good idea.
I think I have most of my stuff downloaded anyway given that I download everything when I buy it, but I do have a second PS3 that doesn't have everything redownloaded to it. I may have to turn that one on to see what I can redownload.
As mentioned above the way to do that is to go to your downloads list which will show all your digital purchases and let you download them from there rather than going through the store.
Just because the store is closing it's not explicitly said that being able to re-download from the download list will be axed as well, but it's probably better to be safe than sorry. I think the only downside for me on this is that my Vita and PSP doesn't have everything purchased downloaded simply because of the crazy small sizes of their prop. memory cards. I might take a look on amazon to see if it's possible to find a 64gig cart still... although they were hard to find even back in the day. If I find one that's affordable I might redownload everything onto it, and depending on available space might try to add some more stuff from the shop before it goes away. (I'm not holding my breath though.)
-
At a glance you might want to look at the enemy shot code - the code was originally developed to allow up to 15 shots to be fired at the same time - enemyShotX and enemyShotY for instance are suppose to be arrays. However it's only declared as one variable/byte so when you run through the aiming code it's looking at and rewriting the variables next to it and likely causing a lot of havoc. That might be why things are running all over the place.
If there's only going to be one enemy shot at a time ever and it's always going to use those same variables, you can rewrite the aim code to get rid of the Z loop and change all the references of enemyShotX[Z] into just enemyShotX, for example. (As well as any other references to [Z] of course!) If Z is also declared as an actual variable in your code elsewhere, then that code is definitely overwriting that as it uses the Z variable for it's own countdown.
Typically when I code I end up leaving the last few variables of the alphabet (w, x, y, and z) to be used in localized loops like this.
-
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.
-
1
-
1
-
-
16 hours ago, BydoEmpire said:I believe all of my sprites are 8x16. The same bolt pngs work fine if I rearrange the order, as do al the other weapons. What's interesting is that all the sprites after the first two bolts are fine (the enemy sprites, for example). However, if I move the tilesets to be the last thing included, it hangs on boot.
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.
-
1
-
-
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. :)
-
1
-
-
On line 150 of the source you have "playerY" typoed as "player". That might be causing both of the unreserved keyword errors.
-
1
-
-
4 minutes ago, x=usr(1536) said:I'm considering this question nonsensical, because it makes no sense.
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.
-
5
-
-
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.
-
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.
-
1
-
-
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.
-
On 11/9/2020 at 10:40 AM, Muddyfunster said:Does JS7800 interpret 320B correctly ? (I know a few folks use that a lot).
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.
-
1
-
-
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.
-
On 10/19/2020 at 8:48 AM, Lillapojkenpåön said:I just started doing something like that, I think the NES has nametable A and nametable B and when you scroll it goes A B A B A B... and you update the one that's not visable
dim tilemap = $2200 ;A (visable area)
dim tilemap2 = $23E0 ;B
If you can shift that data like how you scroll on 2600, then when you have shifted the entire B screen into A, you can just copy the next screen into B, maybe?
But if you wanted to scroll both left and right you would have to have three areas I think, A B C, would that work?
Does making your levels with alphachars take less space than the tiled map or same thing?
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.
-
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.
-
1
-
1
-
-
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.
-
2 hours ago, Lillapojkenpåön said:Thanks, I've tried everything for five hours.. I'm just gonna give up on this for about a year just like I did last time I tried 🙂
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.
-
1
-
-
2 hours ago, Lillapojkenpåön said:I don't understand what you mean, "added to the bank" especially? Could you try to explain in other words?
Any time you're adding a graphic to your program with incgraphic, you're "adding it to the bank". IE: a graphics bank. So by adding it to the bank first I just mean make sure it's the first incgraphic command you add.
You shouldn't need to be switching it to 160B given the font being used in the example is expecting 160A sized sprites - 160B sprites are basically half the size of a 160A sprite. (a 2 byte 160A sprite is 8 pixels, a 2 byte 160B sprite is 4 pixels) What you should be seeing, instead of 3 digits, is 6 half-digits (the left hand side of each digit). The 1's might not be showing anything if the left hand is blank, or perhaps they're looking like the rest of the zero from the digit before them?
For the characterset, if both font.png and testsprite.png are in the same graphics bank then you should be able to just use "characterset font". I'm not sure what the effect of using multiple characterset commands in the program would be or if it's even suppose to be possible.
Also, perhaps change it back to 160A first, then take a look at what values you're giving to palette P3. Maybe it's displaying but with the palette is set to the same color as the background color?
-
1
-
-
3 hours ago, Lillapojkenpåön said:I copied quickscore to my code, what am I doing wrong if
plotchars '1up' 3 20 3 3 ;shows up as 23 ]&
plotchars scoreText0 3 12 3 6 ;doesn't show up at all?
The quickscore code was a complete sample program. If you copied the entire thing to your own code there's possibly conflicts in the dims and characterset/imports going on? Compiling the example.78b on it's own gives a proper output. If you're using your own font, it would have to be designed similarly to what's in the example (digits first in particular.)
I believe the example also requires the digits/fonts to be added to the bank first so the math will hold up, if you have other graphics being added. In the example there's only the 1 graphic/font being included anyway.
-
1
-
1
-
-
Easiest way to remember it would be that 160B is an extra format usable with 160A. The technical reason essentially is a bit in the Display List entries that 7800Basic is creating for you when it plots something. Setting/unsetting that bit would essentially determine if that sprite is displayed as 160A or 160B. 7800Basic handles all that for you based on whether you incgraphic an image as 160A or 160B. Displaymode is only used to set the "base" mode for lack of a better term. IE: 160A, 320A, or 320C.
The same thing happens with the 320 modes. You would select 320A mode with displaymode, but you'd also be able to use 320C sprites at the same time. Or 320B mode and also be able to use 320D sprites.
-
2
-
1
-
-
That's essentially what you'd have to do yeah. When I was fiddling with it in the past I'm pretty sure I just made two equally sized plots, one for the left hand of the screen and one for the right.
-
1
-
-
16 hours ago, Lillapojkenpåön said:Do you have to create your tiled maps differently when using 160B instead of 160A?
My tiles are now half overlapping eachother so the map only covers half the screen.
The process to create the tiled maps are the same however you have to remember the width of a 160B sprite is half the width of a 160A sprite. If your tiled map is still assuming 8 pixel wide tiles from the 160A sample, then it's going to cause 7800Basic to do exactly what you saw happen. You'll have to adjust the tile sizes on your map in Tiled to width of 4 from 8 before exporting it.
-
2
-
-
It might be showing the correct value based on what you're telling it to display. The 6 is in the higher nibble of C - ie the second digit that you're not asking to be displayed - you're just asking for it to display the 0 of 60, if I remember plotvalue correctly. Try plotvalue font 0 score2 2 152 6. Might want to change the 152 to 144.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
160B Mode 7800Basic ERROR, plotmapfile didn't find a palette
in Atari 7800 Programming
Posted
Assuming the quoted code is what you're working with, did you intend to "rem" out your characterset command? I don't know if that would cause the actual problem you're having but I suspect it'd cause other problems later if not. I remember having the error you're mentioning about the palette when I was working on the little screen switching engine but I can't remember how I fixed it in the end.