Topic: Petit Computer

Im making an action rpg game sorta like kingdom hearts but with 2d sprites but Im still learning smilebasic so it may take a while. I think randomous made a loz song, how do I put it in edit not console mode and make it play? As for the tutorial website, how about P.T.C Community?

@Nitras I will ASAP.

Thank you so much!

I'm sort of getting back on track with developing things for PTC but it's been chaotic. Life's kinda wierd that way right?

So anyhow.. This post is mainly about what I want to be working on in the next little while.
First, I have to get back to work on PETIT LTTP. There's alot of spritework and other related work to be done and so little time.
UnfortunatelY!!!! MY LAPTOP IS BROKEN, So I have to use a desktop for the time being which is lamesauce since I can't take it everywhere with me.
This slows down production a little not to mention, the desktop's moniter atm is an eye sore . (OLD CRT) so yeahhhh. erm. It's going to be a while.
When I finally do release petit LTTP though I promise it won't be a dissapointment. I'll be doing alot of complex routines in the codebase for the game and optimizing as much as possible. I realized a virtualized environment for the game would take up most likely double or triple the cpu cycles to run so I'm going to take the route of coding the entire game from scratch by hand rather than creating a higher level interpreter that shrinks the code into compressed Petit Computer code. Sprites are not as hard now and the sound stuff's easy with that converter program that was released. :3

I have another thing I'm working on to starting today. Basically a trade-system template. I don't know how well it'll work since it'll rely on giving the user a code. Having the other user enter that code into the same system, Then, that system takes the code pops out an item, and gives the player who put the other player's code into the system, a code to give back. They give that back, and the other player gets their item. It might be a lengthy process where players have to exchange their "trade codes" multiple times. But manually inputting codes could be a decent system to create multiplayer games that don't rely on a network connection or a wifi connection for that matter.
I'm thinking of designing a networking protocall which uses this system and relies entirely on other users entering the packet data from the other player's screen. I know this seems slow and in efficient but since it would only be used for a few features or things you'd only ever want to do once a day anyways .
I think it could work.

I'm also going to start programming secret codes into my Petit Computer games later. You can go ahead and cheat by reading the game's source code and finding out the secret codes but it would be more fun to discover them and exchange them since the game I'm planning will reveal secret codes that only work on another player's game later. :/ We'll see how that stuff goes down.. and my AI? well.. so many bugs stil.
I still need to work on the pc version :/ it's coming along slow. That's all for now everyone!

Ok, this is bad. It appears that PTC has burned the keyboard slightly into the bottom of my XL screen. I guess all that white during long programming sessions is what caused it. Anyone know if this is something that is covered under Nintendo's warranty?

Just to give you an idea of just how long I've used PTC....well.....in all (including when I was using it on my original 3DS before upgrading).....
.
.
.
........~400 hours. I'd say at least 1/4 of that was with the XL.

Don't know. Probably not covered unless it's major damage. Maybe you can soften the blow by showing reverse picture of the keyboard, and try to even out the burn. Despite long times doing PTC, Animal Crossing is taking up number one spot easy in my case.

Hmm, I wonder if I should go and make a simple program that's used for fixing pixels. I think those are used also for screen burn-in.

@Discostew It probably won't cover it, but you should try. If they decide that it is not covered, you'll have to pay about 70-80 bucks depending on where you live. When my 3ds buttons quit functioning I sent it in. I paid 81 bucks but the guys at the repair did even more. They gave me the max limit of play coins, corrected my time and date, placed dust protectors on my L/R buttons to ensure those don't quit on me again. When I got it back, it was apparent that they put a lot of time and care into it. You may still decide to get your 3ds back free with no repairs when they decide you have to pay. That really stinks though. I know how you feel. I must use PTC with caution now... I guess...
How is MM2 development?

I have a question though; if VSYNC is better than WAIT but does the same thing, why use WAIT? Or am I missing something here...

The only problem I ever had with petit computer was creating scratches in the shape of the keyboard keys in my screen protectors.

Define "better"
WAIT is absolute. If you want to absolutely wait 3 seconds, use wait.
VSYNC is good for timed event that must happen "in-sync"

different purpose, different commands.

Now if you ask about BUTTON(1) and BTRIG, then I have no answer.

@Bluerobin2

I believe the main difference between VSYNC and WAIT is when they finish. VSYNC releases the moment the system enters what is called the V-Blank. It's an area that, for games, allows preparing graphical data for the next frame among other things. The DS/i have 192 visible scanlines, but they actually have 263 lines in total (71 for blanking). So, the moment scanline 192 finishes (and VSYNC was set with 1), control to the program is returned. This means it won't likely halt the code for the entire number of frames given, but more than one frame less (so, "frames - 1" < x < "frames"). WAIT, on the other hand, pauses for the full number of frames, using the system's timer hardware to determine exactly when a full frame is fulfilled.

So, VSYNC is display refresh-based. WAIT is timer-based.

@gimmemorecoinz
Try a hashing solution, as it will allow you to have the users enter the code, but when they look at the source, all they get is irreversible gibberish.

I haven't made anything in a while, and I'm kind of bored so... I'm thinking of making series of games that allow you to explore a world I make. For instance, I could make like a medieval theme world, and you can explore a lot of things. The only thing only thing holding me back (seriously, I've been thinking about this for a long time now), is that I am TERRIBLE at making sprites. I can picture what I want to the last detail in my head, but somehow, I can express it. Anyone willing to make a few castle sprites for me please?? All I need is: 1. The castle sprite of when you're looking in a map, Like the early Final Fantasy's.2: A few human Sprites. Help would be appreciated

P.S: I need to find out what format or pixel count Petit Computer uses for sprites. thank you!!

They use 4-bit paletted. BGs and sprites have access to 16 rows of 16 colors each (actually 15 colors + 1 for transparency). The console/panel take from the BG palette. Writing to the CHR sections is done by 64-character strings that make up an 8x8 pixel block each, so 8x8 is the smallest size for any graphic cell. Each pixel in the string ranges from "0" to "F". Sprites, however, can only access on boundaries of 16x16. Sprites use a sequential list to form bigger sprites up to 64x64 pixels, so if you defines a 16x32 sized sprite, and had its source index to 0, it would read from index 0 to index 7 and display it like so...

0, 1
2, 3
4, 5
6, 7

If you had the source set at 1, it would offset by multiplying it by 4 (because 4 8x8 blocks make up a 16x16 block), so it would do it like this...

4, 5
6, 7
8, 9
10,11

@Discostew thank you Discostew. Very much appreciated.

@Nitras what should I troubleshoot?

http://www.mediafire.com/?wvxtvqacabrpuac
You must install Pygame (from pygame.org) and python 2.x (from python.org).
This is the recreation of CincOS., but better.
If you have any .png, .jpg, or .jpeg files on your desktop, it loads them all. It only works for Windows at the moment, so only execute the one that says "Jupee_GUI_Windows.py". Thanks!

Mostly just the fact that parts of some of the sprites mysteriously disappear when you zoom out (B button). Also, any comments or thoughts you have would be welcome.

@Discostew @ranstring ah, I see... Thanks.

I have also wondered, Is it needed to assign BUTTON() to a variable? Pretty much all the programs I saw use BT=BUTTON(). Why not just use IF BUTTON()==16 THEN BLAH?

The reason for assigning BUTTON() to a variable is so you have access to that state throughout an entire frame as it can change within it. Take for instance BUTTON(2), which returns what buttons were instantly pressed. If you called BUTTON(2) again right after, or any time afterwards, the likelihood of it returning the same state as the first call is unlikely because the buttons were not instant in that second call. So why is this a problem? As an example, take these series of lines.

IF BUTTON(2) AND 16 THEN yaddayaddayadda
IF BUTTON(2) AND 32 THEN doobedoobedoo

This would not work well because you could have the B button (32) pressed during the first line, meaning the second line won't run its course. If you assigned BUTTON(2) to a variable, and used the variable in the IF statements, you'll get the result you're looking for. Even BUTTON(0) is affected by this, as you may end up releasing a button before the frame ends. Another example

IF BUTTON(0) AND 16 THEN yaddayaddayadda (which takes up the entire 100 characters on the line, but you have more to assign)
IF BUTTON(0) AND 16 THEN yaddayaddayadda (which sets everything that couldn't be fit in the first line)

This scenario would not work in the instance where the button is released right after the first BUTTON(0) is examined, because that can happen. The set up is meant for both to execute, or neither. By using a variable to hold the state, you can follow through with both lines.

I hold that helps.