Topic: Petit Computer

Yay!

and explodeing in a shower if limbs and blood isnt !?! at least i wont have that. like the original terraria. well technically i will have the limbs but it wont explode more like... er... pile up on the ground... lol?

lol i dare you to make your limbs go flying halfway across the map and have a limb cam where you can follow your limbs travel across the land XD

so IM the twisted one...

lol

That is just insane...
I wish I was better at this! I know so little about this entire language.
I'm still asking questions on how to use button commands properly!

im not doing 'limb cam'
i dont want to have to include a sideeffects list to my game.
it would go like
WARNING
projectile vometing may occur
please restrain from tearing your eyes out.
make sure your insurance plan covers psychology professionals. inteansive death may occur
WARNING
sounds right

very profesional. no?

Maybe, but then you'd have to move the "bullet" sprite to the place where the touch screen is pressed down at, which is an extra function you'd need to deal with.

I would have to respectfully disagree, not just because my project doesn't use that, but because of the problems that would occur.

First is sprite coordinates. By using actual sprites, coordinates will be relevant to the screen. While being at position 512,40 would net you at the left border of the 3rd screen area of a 1D level (sequentially going from left to right), the sprite itself would not be on the screen at all. It would be way off on the right side, out of sight. This then would require that you shift everything over so the sprite would theoretically be in the middle (or closer to the left or right if the level doesn't wrap around). This would then require that you shift "all" barriers by the same amount, which is just not feasible. You could instead attempt to have "blank" sprites that would represent the sprite that works off of "level-space" instead of screen space, but then you'd have to duplicate all sprites that must work with the collisions.

Second is the limitation of how far a sprite can move. If the +-1024 is an indication, a level can only be 8 screens tall/wide.

Third is the number of barriers in the level. As the space of a level increases, so would the number of barriers that would have to be stored. Even if the level is optimizes so that it stored the least number of barriers (like clumping a horizontal line of tiles to be just one barrier), you'd still have to examine each one to determine whether a collision is taking place. You could attempt a strategy like BSPs (Binary Space Partitioning) so you'd only have to examine those barriers close to the player, but honestly, that would take a great deal of work, not to mention the structure to make that work may not even be possible with Petit Computer.

These are just a few things I came up with off the top of my head. These sort of problems are why I went with the collision method of using the actual tiles themselves and not using sprite collision at all against them. A 2D array can represent the tiles and are based off of tile-coordinates. All I have to do with collision is convert my sprite's level-space position into tile-space, and access the array directly. I'd grab the value/tile from the array, and use that as an index to another array that holds each unique tile's metadata. If the metadata says it is a solid block, then I have the sprite react accordingly. This method allows me to check "only" those tiles that are within reach of the sprite, so no matter how big the level is, the time it takes to check collision is practically even on all accounts.

@discostew for smaller more linear levels though SPHITRC could work with a custom sprite made in Chred that along with vsync 1 with your controls for your character shouldn't create too much lag. How does a newbie like me know? Because it's the codes Im using for my own game Im "working" on.

@discostew thanks for that post. i had read through your background scrolling tutorial and wasn't sure how i was going to handle sprite/background detection. i was about to post and ask how you did it in MM2, but i guess you beat me to it. xD

@Discostew Hey, did you see my post about sprites being processed out of code order? I was wondering if you had any idea what it was: https://www.nintendolife.com/forums/dsiware/petit_computer?sta...

Edit: Oh sorry, everyone's bombarding you, aren't they?

Great analysis, Discostew! Impressive as usual.

However, I guess I need to be more specific.
Problem #1, instead of shifting everything to player sprite, create a doppleganger that is off-screen. Then you need to shift nothing.
Problem #2: So create a game 8 screen wide. There's quite a bit you can do with it. Uh, is that a problem?
Problem#3 BSP? Use clipping technique. I don't see a problem with that. You can clip very easily. Going further, you can specify "rooms" with specific barriers. With it, you can check only a small number of barriers per room. Easily done.

@randomous
Speaking of checking posts, did you see the updated post that shows how I created custom card backs, and how I edit your program to load it? Maybe you can add code to load custom backs sheets. I need to rescan anyway, so I'd rather you put on hooks on your program before I rescan. Thanks.
Edit: better yet, put in hooks to load all card faces, too. That way somebody can write a card drawing program that you can EXEC away!

@ramstrong There are still problems with this method:

The palettes are still set to their old values, so new cards would either have to follow my palettes, or update the palette data. This would require either the users changing the palette data in the code, or the code reading some user-set palette data (from a mem file or something) and setting it accordingly. The big code inflation here is error checking: I don't want the program to misbehave if the users have given a bad palette data file. Another problem is the card size: if the cards were too large or had holes in them, the cards would be rendered incorrectly. Thus, more code would have to be created to test the new cards to ensure that there are no pixels outside the card, and all pixels inside the card are filled. Yet another problem is ensuring the file exists: if users choose to load a custom file, the program would have to adjust if the file later gets deleted. I don't want the program to constantly tell people "This file doesn't exist". Finally, I've set custom colors for many of the palettes to achieve the desired effects, and palette 15 is strictly off-limits (thanks to the felt background). If users used CHRED to create the sprites, they would have the incorrect colors and may use an off limit palette. This is all doable, but considering you didn't want to scan 14 QR codes, I'm not sure that you'd want to scan a program that includes all this massive error checking.

That being said however, I wouldn't mind releasing the "depackaged" version so that people could get at all the resources (minus colors) and do whatever they wanted with them. In this case, I wouldn't really mind if people messed up the cards, because it wouldn't be part of the program. I'm very concerned about providing a consistent and unified experience, so incorporating anything to do with card editing into the program would require me to add ridiculous amounts of error checking to make sure nothing went wrong. With the depackaged program, there's no need to worry, because it's a "do it at your own risk" sort of thing. I hope that's all right... I know I'm being stubborn, but I just like my programs to behave a certain way. I'm really sorry!

First off, you did a wonderful job with Klondike. I'm rather impressed (and yes, I switched the card type to Megaman )

I have a theory, based on my dealing with low-level programming on the GBA and DS's 2D hardware. Petit Computer might be working with a sprite buffer that, instead of updating one sprite at a time like what we do with SPSET and such, all these commands towards sprites gets written to this buffer, then when the system enters the V-Blank phase (which is a section between after the LCD finishes refreshing the entire screen and when it start going back up to start on the next frame), it writes the entire buffer at once into the designated memory area. That would explain why setting up sprites take a bit to update.

Now for GRP writing. Unlike setting sprites, the GRPs are simply backgrounds set for 8-bit images, non-buffered, so anything you write into them immediately takes effect. It does not wait to refresh in the V-Blank phase. Now, I'm not quite sure why VSYNC 1 (which forces code execution to wait until it hits the VBlank phase) doesn't do the trick of not having sprites flicker as they do but doing it twice does. It may have something to do with using SPCLR and SPSET each time rather than setting up the sprites once and then changing them with SPCHR.

That's quite alright. A do it at your own risk is perfectly fine by me. I don't think checking that all cards are solid is a problem. You have the outline of the card, right? I think the problem is checking errant pixels. Who knows? Maybe people wants to have strictly rectangular card, instead of the rounded ones now? Will that cause problem? Or how about round cards? There's too many possibilities to check, so I don't expect you to. But not all of us is stupid. I know how to color within the line. So, I can take the risk no problem. Thank you.

Too bad there's no way to check for sprite's file existence before loading it. But there is a way to check for package existence, so maybe you can set it up so that if the program is saved with packages, then it doesn't load the external data. However, if the program is saved without packages, then it will load the external data. Will that work?

@Discostew Yeah, I probably should have done SPCHR instead... I don't know why I didn't. Oops! Oh, and thank you very much for trying out my program, and I'm thrilled that you like it! And thank you for your explanation, I figured it had something to do with sprite buffers...

Actually... yeah, I think I'm going to just change everything so that it uses SPCHR instead. Really, I have no idea why I continue to use SPSET and SPCLR in all my programs. It would probably get rid of the (very infrequent and rather random) occurrences where the sprite momentarily shows up in the corner of the screen before using SPOFS. Thank you!

Edit: @ramstrong I actually just spent about an hour setting up the depackaged version with (hopefully) extensive instructions detailing how to go about either adding extra cards (it's really easy) or changing the cards that are already there (even easier). I hope you guys make some cool cards for yourselves! I'll post (or edit) when I put it up on the wiki. Thanks for forcing me to do this @ramstrong lol.

#1: Yep, the "blank" sprite trick that was mentioned.
#2: Well, I guess it depends on what sort of game is being made, and whether it can be fit into an 8-screen-wide area. 8 screens wide may seem like more than enough, but I've found that it could very well be limiting. Like, if you have a fast game, 8 screens is nothing. Even Megaman 2 has sublevels which I think range up to 16 screen sections wide.
#3: In such a case, it depends on the structure of each section/room/etc. For instance, a simple room where you have a floor, a ceiling, and a wall one each side would just be 4 barriers that each movable object in the room must check each time. That doesn't seem like a lot, and it isn't. It's when complexity of the room is increased. Take for instance the 2nd screen area of the first sublevel of the 3rd demo level in my Megaman v0.2 game (It's the forest area that has you enter a cave and pop out the other side to the large tree). Just that section alone would take quite a number of barriers to form to give the same exact effect as going with tile-based collision that only has to access the tile array up to 3-4 times or so per movable object, which is more of a fixed-amount of time across all areas. I'm simply stating that the SPHITRC method for use with background collision is sketchy in how much time it takes to process complete areas, which sometimes it can be fast, but other times can be downright laggy based on the complexity.

I could very well be wrong on a number of issues. I mean, I only found out recently about using sprites for timers through position interpolation, and then reading the position to determine how much time is left. That is something I would not have thought of because I've worked so long with direct access to the hardware that I've had to make my own functions to handle them basic operations rather than trying out functions that are meant for one thing but have the capacity to be used for others.

Hah! Just to let you know, the first demo of MM2 kept using SPSET, so rarely, you'd see a sprite piece (like an arm) pop up in the top-left corner of the screen. I did that because the sprites at certain periods would require a different sized sprite piece to animate correctly, so I'd force SPSET on-the-fly. Using SPSET will always wipe the sprite clean, which means it resets all attributes such as positioning, and because of this, takes quite a bit longer to process.....I think. It was the main reason why I had to reinvent my sprite methods, forcing all entities to allocate all the sprite dimensions it will require for animation, setting them up initially as blank sprites with their sizes defined, and then I'd use SPCHR to change them.

@Discostew LOL that would be hilarious! I could imagine playing through and going "Man, this program is amazing!"... and then an arm flashes up at the corner of the screen. I'd still think it was amazing, I'd just laugh hysterically!

Edit: Oh yeah, are you using the Klondike version on the Wiki? Just checking, as the one on this forum is rather old.

Also, @ramstrong I've provided the "depackaged" download option on the wiki now. Let me know if you run into any trouble with the instructions... I know they're a little verbose.

@randomous Yeah, I got it from the Wiki. I was looking at that post you mentioned, and couldn't find anything wrong with lines 306-307. They looked fine to me, so I looked around that area, and found those two lines further down.