Jump to content

flux

New Members
  • Content Count

    49
  • Joined

  • Last visited

Everything posted by flux

  1. A guy who worked on Sonic 3D Blast on Genesis has a video where he showed how he did some of the tricks used on the Sonic 3d Blast special stage for Genesis. There might be something you wanna use on there like how to do the panels to jump over or something like that.
  2. I got stuck on this issue a while back and decided to get back into it and still wasn't able to come up with a solution so I'm going to try reaching out. I have a 1 bit 16x16 single frame sprite that refuses to show up. I tried making a 64x64 1 bit sprite using the same program and method and it seems to load ok (the palette seems off but it's there at least). But the 16x16 version inexplicably refuses to appear. The changes I make in rapinit.s between the two are on these lines: dc.l 16 ; sprite_width ; width of sprite (in pixels) dc.l 16 ; sprite_height ; height of sprite (in pixels) dc.l 1 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24) dc.l 16*16/8 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 16/8 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 16/8 ; sprite_gwidth ; GFX width (of data) dc.l 64 ; sprite_width ; width of sprite (in pixels) dc.l 64 ; sprite_height ; height of sprite (in pixels) dc.l 1 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/64/24) dc.l 64*64/8 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 64/8 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 64/8 ; sprite_gwidth ; GFX width (of data) Besides specifying a different filename in assets.txt, that's really the only thing that changes and I'm not sure why it would show up in one instance and not the other. I did clear out the build files and everything when switching between the two different files. I'm still not 100% clear on the whole dividing by 8 or 2 thing but I feel like I have it correct there. Once, when playing around with those numbers I did get my sprite to appear when I changed sprite_bytewid to 16/2. It was as tall as it should be but was maybe 4 or 5 times as wide, like a big rectangle instead of a square with the graphic all distorted and messed around (not simply stretched). Both 16/16 and 16/4 left me with my sprite still not appearing, and 16/1 gave me an even wider rectangle, perhaps twice as wide. So it may well be the case that I'm doing something wrong in that rapinit.s file but as I have it there in the code paste, it simply doesn't appear at all. (It might also be worth noting I don't have transparency turned on for that sprite or anything like that.)
  3. I remember a sales clerk urging me not to get Wolfenstein 3D, which I was getting mainly because I remembered having a ton of fun playing it on my friend's PC. He kept trynna push AvP on me and I refused. I did ultimately end up getting it maybe a few months later when I started to hear more good things about it.
  4. I played around with one of mine for a bit and the only issue I noticed is that the XYZ buttons seem to require you to press them a little hard. If you have a light touch, you can press them so the button goes to a seemingly pushed down state, but it doesn't register. You gotta be a bit mindful and make sure to give it just a little something extra. The Y button in particular is worse about that. I've noticed it with Z a bit too though. I haven't tried my other new controllers and I never used an original Pro so I can't say how it compares or if that issue with this one is a fluke. I much prefer this to the original 3 button pad though. Everything feels nice. The buttons feel nicer. Never really cared for the squishy feel of the ABC buttons on the original. And the L and R clicks on these are so satisfying. Really grateful Starwander did this.
  5. I guess we're queue buddies! I saw the email come in but I was at a local Fortnite competition my son was participating in, and I didn't want to mess around with it there and preferred to wait until I got home on my computer. Just glad I didn't wait too long!
  6. That was it exactly. I was looking for something like that curframe but wasn't able to find anything. Is there a complete list of those things? I was pretty much going by what was in some default rapinit.s template and if it's not there then I don't know about it. But yeah, I did as you suggested and it looks much better. Thanks again! As a side note, while I was stuck there, I took the time to add some code to capture button sequences for use in things like special moves or codes or something like that. They don't do anything yet, but I can see them and it seems to work pretty well.
  7. I was able to get started from the information in that thread but I'm still having some trouble working through this. I might be mistaken about what is happening, but this is what it looks like to me. Currently I have 6 frames spread over two 3-frame animations. When I press the button to shift to the punch animation, it doesn't seem to start from the beginning. For instance, if I pressed the button while on the second frame of the normal "idle" animation, then the punch animation will start on its respective third frame. I'm not sure if that's exactly, but it never really seems to go through the entire punch animation, and it definitely produces a separate and distinctly incomplete animation based on what frame of my idle animation I start on. My sprite is 80 pixels wide. Each frame is 128 pixels high (so with all 6, the spritesheet is 80x768). I'm adding 15360 when I hit the button, which if I understood the post you linked properly, it the number I'm to add in order to have it play the second animation. I'm storing rlist[P1].gfxbase into a variable before my loop. When the punch button is pressed, i set rlist[P1].gfxbase to my variable + 15360 and then set it back to the variable's value alone after 3 frames. Is there a way to have it reset to the first frame of an animation before it plays? Or is there something fundamentally wrong with my approach here? Any help would be appreciated!
  8. Thanks for the kind words everyone! I did have another question though. I'm not sure how it works with changing sprite animations. Like, say I have an animation where I want my guy to throw a punch. Do I keep all animations on the same sheet and somehow specify which ones to use? If so, is there an in-depth description of that process? The only other thing I can think to do is I would have to have separate sprites for each animation and load and unload them all as needed. Also should I keep all this stuff in this thread or make a new thread for each new programming question I might have?
  9. Ever since I was a kid, I wanted to make a fighting game. I decided to give it a shot with Raptor Basic and have been poking around at it when I have free time (almost never). I had a few hours yesterday to jump back in and got a little bit further along. Keep in mind these graphics aren't final at all. The actual game will look nothing like this. Also there's no actual fighting or collision detection or anything like that yet. You just have a guy that can move and jump around a bit. I think I sorted out my last issues with the scaling that I was stuck on for a while, so I guess that's why I'm stoked enough to make a post about it. When I get something resembling an actual game, I might set up a youtube account or something but for now, all I have is this cheesy cell phone video I uploaded to mega. https://mega.nz/#!dxQUGQKJ!-LPUqbsiJKjvu0_DbeUenVmODidE5B0PwYvcYj0qEe0 I know it will take forever since I'm just one guy but it's fun to work on from time to time.
  10. You probably really should stop doing that, though. Starwander, many thanks for doing this! Just ordered two sets!
  11. That actually looks like it's it. I guess I haven't really looked into the particle layer too much so it's still a bit of a mystery to me. I didn't realize everything on it was relative to the layer's position. I thought they were straight up screen coordinates. That helps a lot, thanks!
  12. I was having an issue with getting the value for the x coordinate located between two sprites. I took the x value for one of them, plus the x value for the other plus its width and divided it by two. Somehow this still seemed to never be quite right and would always look a little off. I plotted a couple of points in a vertical line and set them to the same x value I was positioning one of the sprites at, and it seems to be off. Then to make sure it wasn't something weird with my own code, I tweaked nyandodge a bit and tried the same thing. I added a PX variable to go along with the PY, and set it to some arbitrary value (in this case 40) at the top where I declared it. Then lower in the code, where it positioned the y value, I added this bit. rlist[1].y_=PY rlist[1].x_=PX COLOUR(1) PLOT(PX, 136) PLOT(PX, 135) PLOT(PX, 134) PLOT(PX, 133) PLOT(PX, 132) You can see the results in a screenshot here. My understanding was the the x coordinate of a sprite refers to the left side of it. If that's the case, this line clearly isn't matching up with the left side of that nyan cat. It might be that I don't know enough about how the plot command works or how sprite positions work. If that's the case, could someone talk me through why those things shouldn't line up in that case because I'm scratching my head over here.
  13. It was more a case of I didn't describe the situation accurately and I'm embarrassed to admit I didn't catch it before I posted. At the time, it was so inexplicable that I had no idea what to do. Turns out, I had the wrong variable assignment statement commented out and one of the variables was indeed changing, and at a pretty rapid pace. I didn't look into it enough to investigate why it kept the correct digits at the front. It seems like it ought to have been more random than that but I was just happy to get rid of that whole thing. However, and maybe this isn't the best spot for this and I should start a new thread. There does seem to be some other unrelated weirdness I can't seem to get straightened out. I have a couple of variables for my sprite's x and y coordinates, and sometimes I will print those values to the screen when such information is useful. The problem is that half the time, the numbers seem to jump all over the place. My x coordinate will jump from 100 something to 600 (well outside of the area for the resolution I'm at) and then maybe back down to something else and then at some point return to something expected and normal. The weird bit is, as near as I can tell, my sprite isn't jumping around accordingly. It just keeps moving smoothly and steadily around the screen. I haven't worried about it too much yet since it doesn't seem to actually break anything. I'm sure I'm doing something wrong and I'll figure it out eventually, but does that sound familiar to anyone? On a related note, is there a way to look up and return the current properties of an object such as its coordinates or flip status or scale value or is the only way to do it is manually track that stuff with variables?
  14. I seem to be getting incorrect results when I'm adding two variables together. I'll call them A and B for example. If A=178 and B=296, the answer I get when I add them and store the answer in variable 'C' and print that variable to the screen is 47495680. The first three digits are the correct answer, and no matter what values I set A and B to, the first digits will always be accurate. But it seems to be appending a bunch of digits or multiplying it by some hundred odd thousand or so. There's no other code changing these variables between the time they're set and when they get printed to the screen. Am I running out of memory or reaching some other kind of limitation? Everything seemed to be going well previously... Edit: Disregard. I think I figured it out. But there's no way to delete a post here? Even if it has no replies?
  15. All three of them seem to mostly work now but I still have one minor issue with all of them, that is, the very bottom pixel row of the feet isn't showing up. I'm fairly sure that I have the three frames lined up properly in the bitmap but if I don't, then I'm happy to be told where they're wrong. Or, if it shows up for you properly, then perhaps the issue is in my code somewhere. Much appreciated that you took the time to fix it. I was not expecting any kind of help on that level at all. I thought maybe I'd get a suggestion to use such and such program and export with certain settings (which, if that's what it takes to get working, I'm all for...). In any case, I'm really grateful.
  16. There might be something to the idea that there is something wrong with my bitmap. The original was exported by photoshop. Then after reading your post just for fun I opened it in gimp and saved it without making any changes. This version made it monochromatic in the game. My character turned from having a skin tone to being solid black, and if I turned transparency off, it made the background color for the sprite a shade of gray. But, it cleared up the horizontal wrapping with the back of his foot wrapping to the other side. It also cleared up the row of pixels showing up at the top. What it didn't fix is that row is still missing from the bottom. I opened up that one I saved from gimp in photoshop and saved it without making any changes, and it restored the color, and kept the fixes with the wrapping, but I am still missing that bottom row of his feet. They just vanished altogether instead of showing up in the wrong spot. Also, I don't know if it's worth noting, but all three versions of the file -- photoshop, gimp, photoshop again -- they all have different file sizes. Even the two photoshop versions are different from one another. By only 4 bytes in that case but still. I put the three versions of the bitmap in a zip file here https://mega.nz/#!ZhozzQ6R!Seqn3TRuP9RVnoZgqrmVH4M1-cLbEOTsHxkEtoWTOXQ if you want to have a look at them. If there's a more preferred method of sharing the files, I'll be happy to put them wherever I'm supposed to. As for my project, there's a ton of experimental garbage all over it and I'd like to clean it up a bit before sharing, so I'll try to get to that some time today.
  17. Well, dang. I was afraid you'd say that. It is an embarrassingly crude placeholder stick man. Just trying to get pieces in place before I get into the final graphics. A link to the sprite sheet and a screenshot is here.
  18. Ok,hopefully the last issue of the day. I'm trying to load a 96x128 sprite with three frames of animation (so my bitmap is 96x384). It mostly works, but on two of the frames, the very bottom pixel row of my character's feet appear as the top row of the sprite, sort of floating above his head. On the third frame, it seems to be a thin row of random junk pixels as the top most row -- still with the bottom row of pixels missing from the feet. Additionally, the very back of his foot what should be on the left side of the sprite is appearing on the far right edge. Also, while the bottom of my character's feet is indeed on the bottom edge of each frame in the bitmap, the back of the foot is not against the edge and there is some buffer space there but some of his foot still seems to be ending up on the wrong side of the sprite. As near as I can tell, which is by no means an expert analysis, all of the sizes are properly specified in the rapinit.s. The parts I'm most unsure about are these: dc.l 96/2 ; sprite_hbox ; width of collision box dc.l 128/2 ; sprite_vbox ; height of collision box dc.l 96*128/2 ; sprite_framesz ; size per frame in bytes of sprite data dc.l 96/2 ; sprite_bytewid ; width in bytes of one line of sprite data dc.l 96/2 ; sprite_gwidth ; GFX width (of data) I pretty much copied it from some of the included examples, substituting my own dimensions. But I don't really know what's happening or why I'm dividing by 2. It gets reasonably close results and whenever I try to change any of these values, it gets worse. I'm pretty sure the bitmap itself is fine. I checked the first 128 rows carefully, as well as each one, and made sure each was the size it was supposed to be and that everything is where it ought to be. Now I'm out of ideas.
  19. I have another issue. How is the color that gets used as a transparency determined? I thought it would be something in the rapinit.s file but I don't see anything there besides switching it on or off. Is it something within the bitmap itself?
  20. This is the other part of what I was missing and I didn't even get this bit until I just read this post. I wasn't sure what the ; sprite_CLUT value was exactly, and I mostly just copied the whole lot from something else as a reference and tweaked it as needed for things like dimensions. I assumed this was just a flag that was on or off so I put that setting as "1" for all my objects, since "1" worked well enough for the one I was referencing then it ought to work for everything! I was able to fix it with the thing I mentioned in my previous post, but this explains how it ended up that way to begin with.
  21. I think I got one of my major hurdles cleared. I would load my various cluts, but for some reason I couldn't ever get my background object and my player object to use a separate clut. I tried loading things in different orders and all of that kind of thing and it occurred to me that there was nothing in my program explicitly assigning a specific clut to a specific sprite. I suppose as I was initially figuring everything out, I assumed a clut number was intrinsically linked to what I was using for the object numbers. Not for any good reason -- just working backwards and trying to figure out what does what. In any event, once I had that epiphany, I looked it up in the quick reference guide and figured out this gem which solved a whole heap of my problems. rlist[2].CLUT=2 I think that has me squared away for now but I'll probably be back next time I get stuck. I like to think it will be a little while, but probably not.
  22. I guess specifically I was wondering how I get the "global" (so to speak) 256 palette loaded. That is, is there some syntax where I manually specify each of the 256 rgb values in my code? Loading my objects normally doesn't seem to work unless I'm doing something wrong there. That is, my 8 bit object which uses 200 colors and my two 4 bit objects seem to interfere with one another's palettes despite there being room for all of the colors. So my thinking was that maybe I need to manually define a palette and every rgb value, or maybe I need to first create a bitmap/object that has the 256 colors I want to use, and use that to define the palette that my other objects will then use a subset of?
  23. That actually pretty well resolves one of the key points I couldn't understand. Thanks! If one wanted to divvy up the palette between different objects, how is that done exactly? For example, like I mentioned in my initial post, my background sprite currently uses around 200 colors which leaves more than enough for the other objects which are each 4-bits. Yet, as soon as I include those 2 objects, or really only one of them even, it messes up the background object and the background starts taking on colors of the other objects. What is the mechanism for getting these 4 bit objects to use colors outside of those in use by the 8 bit object and instead use some of the leftover space for them? Currently, the palettes seem to pretty much be getting determined by the bitmaps themselves. Is there something I'm supposed to do to manually define the palette instead and specify each of the 256 colors? Seems tedious but if that's what has to be done. Or am I supposed to first include some kind of bitmap that contains the entire palette I want and just not use it in the game and instead only use it to define the palette that the other objects use? Or does it have something to do with the order in which the assets are loaded? Sorry if these are dumb questions!
  24. First, I'm having trouble getting text to show up over my sprites -- my background sprite in particular. It isn't clear to me what I should add or move around to make this happen. What do I need to make sure I am doing with the rprint or other related commands to fix that? Speaking of my background sprite, currently i have an 8 bit image serving as the background. It actually is made up of about 200 colors. By itself, it seems to display fine, but when I add my little sprites (currently two different 4 bit images), then all of a sudden big chunks of my background start getting discolored and seem to be taking on colors from the other sprites. I came across a post on this forum and I could be misinterpreting it but it seemed to be saying that the 4 bit palettes I'm using need to be a subset of the 8 bit palette. This is the part I'm having trouble wrapping my head around the most. I thought that the system could display 16 bit color, and, I mean, of course it does. But is it an either/or type situation? Meaning, if I use a sprite with a limited palette, then I am committing myself to such restrictions in my other sprites? I know this has undoubtedly been explained before and I've even read some things here but it's not really "clicking" for me yet. If anyone wouldn't mind indulging me and explaining this again, and perhaps field some followups should they arise, I'd be super grateful.
×
×
  • Create New...