Topic: Petit Computer

alright now it wont let me do anything else since its in a loop. How do I fix that? How do I make it do other stuff BESIDES THE FRIGGIN LOOP, UGH.

if your done with the loop, use the "goto @(whatever)" to do something else

Trying to get into programming and came across this a few days ago. Finally got the money to get it, but I'm currently on the fence about it.

@ZennyBoiz GET IT. YOU WILL NOT REGRET YOUR CHOICE.

Im never done until u die, its one of those survival games. So it constantly goes up...now what?

@Mrsirr that was just an example. Just use LOCATE and put it wherever. If you have a main game loop, then put that code there (Without the @LOOP stuffs)

Alright, I will definitely go get it once I'm at home and get cracking at it.

Wow. 10HR drive. Doesn't sound like a relaxing vacation. I'm a driver so I regularly do 12+ hour drive. It can get tiring sometimes.
BTW, did you analyzed the picture format? I'm thinking that it would be a good way to transfer data from Nintendo DSi to PC. I'm thinking it's raw 8 bit format 256x192. Is that right? Does the image has header files and does it use a compression at all? RLE maybe?

Excellent explanation, randomous! Do you mind reposting this in tutorial thread?

It's the difference between command and function. Function returns value. Iconchk() returns a number, right? That's why it's a function, and uses parenthesis.

Is there an easier way to use BGPUT with 2x2 background tiles? In my data, I have to code the tiles like this:

32,33
64,65

That is just for one tile, and it's a little annoying having to figure out all the right numbers for each tile. I was wondering if there was an easier way to place a tile, like just by putting 32 in.

GRP PTC files are made up of a 48 byte header and a 49152 byte data section (which is the 256x192 bitmap). The header is as follows....

4 bytes - "PX01"
4 bytes - Data section size (for GRPs, it is a constant 49152)
4 bytes - PTC file type (always 2)
8 bytes - string - internal name of the GRP as read by Petit Computer
16 bytes - MD5 hash string (based on Data section)
12 bytes - "PETC0100RGRP"

GRP PTC files, excluding the typical 48-byte PTC header, are 256x192 pixels in 8-bit format with no compression, but the way they are stored is not what you think. It doesn't store them in rows of 256 pixels each from left to right as you would expect a bitmap to be stored. Instead, it's a bit closer to how CHR data is stored. The entire image is broken up into 8x8 pixel blocks, but it doesn't end there. There are then 8x8 blocks from left-to-right, top-to-bottom, making up a 64x64 section. Then, the entire image is made up of these sections in a 4x3 manner (to make 256x192 pixels).

The following is in C code, which I use when compiling my game assets into GRP files. I write the data sequentially into "readStream", which is an array of 49152 bytes (256x192), and then read from readStream to "outStream" (same size array) in the manner the GRP format is designated.

for (int j = 0; j < 3; j++)
for (int i = 0; i < 4; i++)
for (int y = 0; y < 8; y++)
for (int x = 0; x < 8; x++)
for (int yy = 0; yy < 8; yy++)
for (int xx = 0; xx < 8; xx++)
outStream[(j * 16384) + (i * 4096) + (y * 512) + (x * 64) + (yy * 8) + xx] = readStream[(j * 16384) + (i * 64) + (y * 2048) + (x * 8) + (yy * 256) + xx];

Perfect! Thanks for the info. I'm not aware of being able send GRP files directly. I assume then you're using PTC Utilities to convert graphics to QR code.

Pretty much, unless I find a faster way to generate the QR codes for both GRPs and PRGs. A PRG has the same header with minor changes, with the Data section holding the code in a non-compressed format. At least with that, it isn't sectioning the data like GRPs do, to my knowledge.

I was having issues just like yours also. though there is always the chance were still talking about two different things . I was writing something and I drew up a 64x64 sprite ,saved it SPU0:. had to figure out what number it really put it at . any way it was 0 . got it to work . then i drew up some 32x32 sprites and tried putting them on the same page as the 64x64 one.did the same silly formating thing . I could call I up but it would show up mixed up . I tried everything , keeping the two on the same page , but it would only ever mix em up. well I got to looking and if you look at the pages spu0 0-8 or what ever, i realized they all had the same size sprites. per page or least looked like it . So I got an idea.I kept my 64x64 sprite where it was at; SPU0:SPONGE. saved . opened the editor load it again. went to the SPU page with the 32x32 ,SPU5, drew my sprites saved it as SPU5:VEGIES.
exited. in my program i loaded both the SPU pages just like they were typed in above. it worked . but wait . i turned of my ds . then tried it again and it was displaying the original boy sprite. Long story short. I seperate the sprite sizes and even though when i saved I saved it as the SPU5, I found out that in my program it had to be loaded as SPU1 . I had four vegies drawn in there, locations turned out to be 64,65,66,67. I think it only worked the first time when it was called SPU5 cuz i had originally loaded the CHRED from the cmd prmt then loaded the program with the sprites, with no CLEAR or ACLS so it must have still been in memory.

Below should be my petit computer qr code for a 3D square room animation. Its called wall2. You can use the D pad to move in and out and right and left. Maybe someone can make a 3D game. Question: with the room background tiles, how do I make them bigger?

Hey im new here and till now this had been pretty cool

@Swordx since you can't make the QR codes for Dungeon Adventure could you let me make them for you? But i would only be able to do it today,and tomorrow i would only have a certain amount of time to make them.

hi

I just charged up my ds... after 3 months. just for the proggramm

Is there any way to loo up and down? I also cant seem to turn around after I walk backwords from spawn,can you fix that? And last thing,is there a way to make it go faster? Sorry for all the complaints.

I don't know how you're doing it now, but the way I do it is that my levels are made up of tiles in an array, each element representing a tile value. My sprites have an X/Y position within a level. The collision boundaries are offsets of that position. I take those offsets (relative to the entire level), divide the X/Y values by 16 (I use 16x16 meta tiles, but for 8x8 tiles, divide by 8) to convert it to tile space. Then I use that result and access the array that holds the tile information of the level. I then access another array that holds the attributes of each tile, using the tile value I grabbed from the level array. Each element can hold multiple attributes in bit-form (like 1 = solid block, 2 = ladder, 4 = water, 8 = deadly spike, etc). I then simply examine the tile attributes and how I react to them, like if I'm moving right, and I find the tile I examined is a solid block, then I shift the sprite to the left, making it flush against the tile.

to reduce the amount of examining, only examine the sides that the sprite is moving along. If you're moving to the left, only examine the boundaries on the left side. If you've moving up, only examine the boundaries on the top. The likelihood if needing to examine all opposite sides is very minimal.