@randomouscrap98
Eh. I've changed the qr to v25, upped the cap per qr to 950 characters, and reduced error correction slightly (I think. I'm not positive). A 20 paragraph lorem ipsum (previously 6 qrs) is now 4 qrs. I've changed the zlib compression to 9, but it didn't reduce to 3 qrs or anything. It might be more noticable with larger texts. I'm working on the stitching bit now
@GeekDude That's awesome! But it's really hard for my ds to scan the larger QR codes. What size does SmileBoom use; do you know? Also, it's funny that you're working on a stitcher now, because I made one a little while ago too: http://petitcomputer.wikia.com/wiki/Petit_Computer_QR_Stitcher
All it does is stitch though, so it's not that impressive. But you can give it any size qr code by any name! Lol it's so advanced! (Not really). I realized after I made it that PTC Utilities already stitches QR codes together, so it's kind of useless unless you're using the Smile Boom converter (which I do).
@randomouscrap98
I decompiled smileboom's converter (not sure how they feel about that) and it seems PetitEditor was closer to the money than PyTC. From what I understood of their source code, their cutoff value is 630 (like in PTE), their QRCode version is 20, and they use medium error correction. I will adjust my settings accordingly.
To erase characters with more than just the first 2 8 bit characters, I would want something like "for c in unchecked: if c >> 16 == 0: checked += c", so that the new string "checked" would not contain any of that stuff.
What'd you write your stitcher in?
EDIT: I just stopped playing animal crossing to edit PyTC, it now outputs the same qr codes as smileboom (well, except for margin size, but that doesn't count)
@randomouscrap98
It is written in flash, also, I've edited my above post. I didn't notice yours until after I edited it.
Because I'm writing in python, it is actually cross-platform. I'm only distributing windows executables right now though, because libraries are a pain.
@discostew i was away from my computer for the last day or so, but thanks for the info. I have not been able to recreate what I saw (sprites being overwritten), but when/if I do, I will post a picture. Thanks again for the help.
One another note. If i am having sprite 'A' firing a bullet (sprite 'B') at sprite 'C', how do i check to see if there is a sprite in way as the bullet travels from point 'A' to point 'C'? I imagine I should be checking each frame to see if SPHIT has been triggered for the blocking object, but I do not know how to implement this. Thanks in advance.
@midasmulligan - It's pretty simple, though maybe a bit odd to get started. Unless I'm mistaken, each sprite, when created using SPSET, already has a collision box set, and that it will collide with any other sprite set up the same way (you can change this with SPCOL). You simply use SPHIT each frame to check what it hits, but be careful. If the sprite was made with SPSET and not had SPCOL used to define which particular group to interact with, you may end up having it "collide" with something you don't want it to collide with, like the bullet with sprite 'A' as you fire it. So, unless you attempt to change the "group" interaction with SPCOL, you should make some sort of reference to each sprite. When you use SPHIT, you examine that statement to see if it hit something.
IF SPHIT(MYSPRITE)==TRUE THEN ......
If it is true, then examine SPHITNO to see which sprite you hit. If it hit a sprite meant to collide with it, then do what you need to do with it, as you have the sprite number. If it collides with something it wasn't meant to collide with, then you'll need to run SPHIT again, except this time, set the optional 2nd argument to the next sprite "after" the one it found.
IF SPHIT(MYSPRITE,SPHITNO+1)==TRUE THEN .....
Maybe not in that particular way, since the range can only be from 0 to 99 (though I do not know if it will error if out of that range), but it allows you to scan all sprites until it either hits one you want the sprite to collide with, or none at all.
One other thing I just thought up. Don't have every sprite check every sprite for collision. That would likely be too process-demanding on the program. Take the scrolling shooters under the Game examples. While I haven't dived into the code myself on those, I'd imagine it works like this. Only a couple of things are examining collision. The player ship to all the enemies, their bullets, and powerups. That's one collision testing routine for the player ship. The other are player bullets against enemies. There's no real need to do collision tests with the enemy ships or bullets against the player, since the player is already doing this test against them.
@Discostew If you compress the graphics using C#, won't you have to decompress them in the game? Will that be annoying in BASIC, or is it a simple compression scheme?
@randomouscrap98 - Yep, that's the point. I'm not worried about how many QR codes I'm going to have in the end. I'm trying to fit as much data into the GRPs as I can, since they will be my data bank. I don't plan to loading any external files. They'll all be packaged together into a single file, spanning a single set of QR codes. The actual decompression schemes don't take long. In fact, it may even be faster to read the compressed data and decompress them than to read them uncompressed because reading/writing GRPs is really slow, especially since you can only read 1 byte at a time.
Discostew
3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew
@Discostew Yeah, that makes sense. It is incredibly slow to read from a GRP, so even at the expense of processing time, it would make sense to put as little as possible on it.
So before I delve into details, does anyone read homestuck? If you do then read on. If you don't feel free to go here -> http://www.mspaintadventures.com ...did you finish reading it yet? No you didn't, it's thousands of pages long, but you should at least be familiar with strife. I've decided for my first project that I would make a strife game based on homestuck. A sort of endless, turn-based fighting game. As you fight, your mangrit (attack power) and healthvial (health) increase, but the endless waves of monsters grow stronger as well. The only problem i'm going to have at first is making custom sprites. Does anyone know how to do that and could perhaps teach me?
Why can't it just be really thorough and call it "Petit Computer Community Tutorials"?
Sorry to be inactive last week. I hit my Internet usage limit at 5 GB. Anyway, I'm back!
"PTC Tutorial Community" has a nice ring to it. PTCommunity is not advised. When you type it in Google, it came up with a different website. We don't want that. It may get us C&D letter from them. Since the BlogSpot is "petitcommunity", the logo should match also. Furthermore, googling it will yield the website. Unique name is very important!
Need contact info on the BlogSpot so I can email you my email.
@Discostew no no no
IF C=200 THEN C=3
Something like that over and over
Discostew is right. Think about it. GRP only has 8 bit values on them. Color info is 24 bit. So, GRP has no RGB values. Instead, it reference a color look up table (CLUT) that is COL file. You assume that color 200 is closest to color 3, but you cannot assume that with custom palette/CLUT.
@Discostew I haven't looked up the source yet, but if closest color is too slow, then I assume you do not use look up array? As in,
COLOR# CLOSEST#0 01 12 2and so on16 017 1518 14and so on
That was supposed to be PRE table. How's this?
C=(color index)
COLOR = CLOSEST(C) where CLOSEST is array containing the closest color index of C. That way, you only have to compute 256 values once, instead of every pixel.
EDIT: It doesn't work with Floyd-Steinberg algo since it carries over the difference with various neighboring pixel. Sorry! End EDIT
Also, I don't think loading GRP takes that long, considering it is fast enough for FLIPNOTE app. Array manipulation is quick, but I think it's limited to about 5000 operations per second? You may want to try out comparing decompression time with GRP loading.
One another note. If i am having sprite 'A' firing a bullet (sprite 'B') at sprite 'C', how do i check to see if there is a sprite in way as the bullet travels from point 'A' to point 'C'? I imagine I should be checking each frame to see if SPHIT has been triggered for the blocking object, but I do not know how to implement this. Thanks in advance.
My Petit Computer Journal Trigonometry covers this somewhat. Look for Petit Computer Asteroid program.
@ramstrong I noticed that right after I posted. Sorry. What do you think of our site progress?
Need a few more links: Contact Admin, FAQ, Chat room, Some lesson plans.
It would be nice if you put some posts in there as well, detailing the various milestones/progress. Otherwise, it looks too static. Need new logo (Not PtCommunity).
It keeps getting better, but I bet it'll be even more better, faster once you have a few admins going into it.
Does anybody know whether MD5 checksum algo would be easily implementable in PetitComputer? If not, I'll come up with an RNG-based checksum algo.
Forums
Topic: Petit Computer
Posts 2,921 to 2,940 of 9,620
Please login or sign up to reply to this topic