Topic: Petit Computer

You probably don't want to use the center pixel for overall color. Imagine a black screen with white pixels on the center. You'll end up with white screen, instead of black. Average/Most frequent color choice isn't that hard to do, and a substantial improvement. It's your call, though.

@Discostew
You impress me every time you post, you know? Floyd Steinberg algorithm? That's some heavy-duty algo you're using there! I certainly would like to see it in action. Maybe you can post a tutorial along with it?

All this talk of fancy algorithms and code makes me feel sad about my (temporary) feelings of triumph at making a quick algorithm to mimic butterfly movement for Village... And I thought it was pretty cool...

<End of fake sadness>

On a more serious note, @Discostew all the work you do is really awesome. You too @ramstrong!

Edit: What a lame sounding algorithm when compared to "Floyd-Steinberg dithering algorithm": butterfly movement haha.

@Bluerobin2 That was just an example I pulled from the internet. However, my existing project still has a use, as I can use the color quantizing portion to determine the appropriate 15-color palette, which is relatively quick. I did have to fix a few more bugs in it. It loved to bring up "Division by 0".

@ramstrong and @randomouscrap98 I didn't know about these algorithms until about a couple days ago. I only knew such algorithms existed beforehand.

Okay here is version 1. I nominate @randomouscrap98 to go first, because if everyone went at once we would not have a nice complete product. While making last-minute checks, my 3DS screen started flashing black. I will not touch that thing until nintendo fixes it. I also hope that none of my petit computer information gets lost. Lets be organized; here is the list of people making updates in order:

• @randomouscrap98 (Music, faster speed?)
• @Discostew (Pixelization process)
• @ramstrong (cleanup, other randomness)
• who else?

Please note the following:

• I did not have time to fully do a final test because my 3DS is a ticking countdown to a break-down please fix any errors you see.
• The Send/Receive feature is NOT FULLY TESTED I need someone willing enough to do that
• If the button controls do not work correctly, it is not my fault. The anolog input for my A and B buttons is 0.5 the whole time (Meaning the 3DS thinks that they are half pressed) I hopefully will get that fixed.
• If you do make noticeable changes please post a video or take some screenshots; I would love to see what others are doing with my program.
• I gave credits to those who are helping me at the top of the code using your pen names. Feel free to change/remove if you wish.

Understand? Here are the QRs thank you all.

Lets see what we can do!
Again thank you

I've been working on my part, but one of my original questions has still gone unanswered. Am I to create a new 15-color palette from an image that gets "imported", or am I to use the default palette during pixelization? The former means I'll end up messing with GUI colors as they use the default palette on the first row. The latter means I can't use color quantizing because I'm not creating a palette, so I'd have to examine the pixels to figure out closest-color comparison of the image to the default palette. In either case, the GRP alone is not going to be enough in terms of importing, and will require having a COL file to accompany it.

Ok thanks.

@Discostew I mean the standard, First row colors. How would you need a custom palette? Use colors 1-16 (We do not want transparent).
If that doesn't answer your question, I don't know. Check Version 1 I guess.

So Village now has bugs that fly around, and I thought I'd share the algorithm for their movement. I know nobody asked for it (and probably nobody will use it), but here it is anyway.

My goal was to create a fluid motion algorithm for bugs that was quick to run so I could do it 20 times per frame. As it is, only about 6 fish can be processed per frame, but I wanted there to be way more bugs than fish. Thus, the bug algorithm had to be roughly 2.5 times as efficient as the fish algorithm, so "Challenge Accepted" I guess.

The first thing I took away was collision detection. Since they're flying, they might as well be able to go wherever they want, right? Next, I had to decide how I wanted their movement to actually look. Well, bugs don't really fly in straight lines, do they? They kind of... swirl around, looking for the right updraft to keep them in the air. What better way to make bugs swirl than to make them fly in a circle? To make something go in a circle, you can use the following position transformation (where X and Y are position):

X=X+RX*COS(T)
Y=Y+RY*SIN(T)
T=T+1/16

If anyone knows about polar coordinates, you'll immediately notice this is similar to converting from polar to Cartesian (kind of). Anyway, RX is the width of the circle, RY is the height (If RX == RY, then it'll be a circle), and T is the angle. Notice that I'm continuously increasing the angle T, this is to simulate "going around in a circle" (remember, 360 degrees==0 degrees, so it'll repeatedly go around in circles just by incrementing T). I didn't use a nice fraction of PI because 1/16 is faster to compute than PI/48. OK, so now all my bugs are flying in circles, and although I can make the radius random, that's still pretty boring (and highly predictable, considering they're following the same circle forever). Let's fancy it up a bit by randomly changing the radius to suddenly be -1 times the radius (basically flipping the sign). But hang on, if we do that any time we wish, the bug will jerk around! It'll make all these partial circles and kind of fly in a "hopping" manner. What we really want to do is only change the radius for a direction (X or Y) when the bug isn't going in that direction. Basically, if it's only flying up or down (meaning cos(T) is near 0), then it's safe to change the left-right direction, because it won't show (since it's not travelling in that direction). Same for changing the up-down direction when only travelling left-right. So now the bug movement looks like:

X=X+RX*COS(T)
Y=Y+RY*SIN(T)
T=T+1/16
IF COS(T)<1/10 AND COS(T)>-1/10 AND !RND(2) THEN RX=-RX
IF SIN(T)<1/10 AND SIN(T)>-1/10 AND !RND(2) THEN RY=-RY

Ewww, but it's not that bad. 1/10 is our "accepted range" to 0, so basically all this is saying is: "Change the X direction if we're not really moving too much in the X direction. Same goes for you, Y". So now the bugs fly in random quarter circles basically, since at each quarter of a circle (top, bottom, left, right), the bug isn't moving in one of the X or Y directions. However, I still want it to be fancier, and this algorithm isn't that long yet, so I still have room. Right now, the circles are all dependent on RX and RY, and if they don't change in the loop, then the bugs are stuck flying with the same radius all the time. Even though it's pretty random quarter circles, you'll still notice the pattern. So, one more change should do it, and it's the rate of angle change. Because this is a "hack" circle movement, the rate of change for the angle ALSO determines the radius of the circle. Crazy, right? Well... I kind of made it that way on purpose lol. Why change the angle just to change the radius instead of changing the radius directly? Because it's easier! We already have a nice rate of change: 1/16. All we have to do is multiply this by some random fraction and TA-DA! We get a a rate of change which itself randomly changes on each loop cycle. Here's the final code:

X=X+RX*COS(T)
Y=Y+RY*SIN(T)
T=T+1/(16 * (1 + RND(4)))
IF COS(T)<1/10 AND COS(T)>-1/10 AND !RND(2) THEN RX=-RX
IF SIN(T)<1/10 AND SIN(T)>-1/10 AND !RND(2) THEN RY=-RY

Remember, RND can return a 0, and dividing by zero is bad, so we'll just shift everything over by 1. What does randomly assigning a rate of change on every frame do? Well, it makes the circles... not really circles anymore. It's more like a squiggly line, since the circle can have a slightly altered radius at various points. Here's an "illustration" (paint) which shows the basic progression of the algorithm from circles to squiggles:

Well, sorry for taking up forum space with useless stuff again! If you'd like to see the bug movement in action, it's in my Village game: http://petitcomputer.wikia.com/wiki/Village

@Bluerobin2 I got it implemented. It does the following...

Through the LOAD button, it loads the GRP and then examines it on whether it is limited to 15 colors (which all pixel art saved through the program will be). Because scanning all pixels would take a bit to process, I made it so that it checks the center of each 8x8 block. If they comply to the 15 color limit, it then checks the upper edge of each 8x8 block to see if it matches the center color. If after this is checked, and it all complies, it then simply loads the blocks as LOAD should. But, in any case where it reads a color greater than 15, or the upper edge of an 8x8 block doesn't match the same color as the center pixel (meaning it is not a true 8x8 block), it is deemed an "imported image", and requests a COL file. THE COL file gets loaded. Then, the color index of the center pixel of each 8x8 block is compared to each of the standard colors via NearestColor algorithm using the Distance formula. Whichever standard color is considered to form the smallest distance away from the source color, then that standard color is set for that pixel. After that, each pixel is read into the BG layer, and importation is finished. It even compensates for any transparent pixels, forcing them to White like many PC programs do when converting images to formats that don't support transparency.

While I could attempt to get the average color of each 8x8 block, that would just take too long to process, and since we are only dealing with 15 colors, the resulting average probably wouldn't be much different anyways. I'll have my version built into QR codes by tonight.

@Discostew Brilliant! What do you think of my program/code? Thank you very much.

@Bluerobin2 It took me a bit to look through, just to make sure any variables I used didn't mess with ones reserved for other operations. The interface looks nice and simple as well.

Figure since I had a little time left, I'll get the codes to you right now. It's named PIXEL2, so it won't overwrite your current PIXEL prog.

@Discostew Great! One question though, Why did you comment-ize my save/load character filter?
Also, I do not understand why you have to custom load a COL. And why the menu won't retract if the file you loaded is not found. Also can you hide the menu while the pixelization process is occuring? It looks kinda ugly.

@Bluerobin2 Opps, lol. I had been testing with a GRP/COL combo that had a "_" in it, which is perfectly valid with the LOAD command, but your code prevented me from using it, so I commented that portion out. You can uncomment it back.

I do have my test GRP/COL if you so wish to try it and see how the result looks after it gets processed. Be warned....it is MLP-related (like my avatar).

GRP - 40 codes
COL - 1 code

As far as the custom COL is concerned, I probably should have took into account an image that uses the default palette, but uses more than 15 colors. I was in the mindset of a GRP that was created along with a custom COL to make the actual image look as close to the original as possible. I was also mainly concerned with just getting the pixelation process working, so things like if the GRP/COL names are invalid is not something I worked on other than if they directly affected the process.

@Discostew, soooooo in short; You're not done yet.
Unstable programs bug me :/

Hi! I'm a bit new to the PTC scene, but I've programmed in a variety of BASIC before (QBasic64 IIRC). I've made a version of minesweeper, but it's console based as I have no idea how to work the graphics/touchscreen commands. Minesweeper is, in itself, a pretty simple game. The only confusing part is getting it to expand the blank areas properly. I made this game because I bought a minesweeper game in the eShop and it was pretty bad. My version, while lacking in graphics, has a randomized board, and properly expands when a blank area is selected. The background music is Mission Impossible, because it was the only fitting music I could think of.

The reason the expansion is difficult is because to do it properly/easily, you need to have some kind of recursive function (I'm sure theres another way to do this, but not one as easy). Functions are not supported in SmileBasic, so the next best thing is to have a subroutine writing to a stack. There is, sadly, no stack either. I wrote my own stack using string concatenation, but it might be better to have an array with it's size maxed out instead.

Please excuse any sloppy coding practices, as I said, I'm a bit new to SmileBasic, and the touchscreen interface along with the line limit, and the lack of multi-line ifs complicates formatting a bit. I did the first bit of it on my computer with Notepad++ and the web-based PetitEditor. PetitEditor is odd, and I would like to write an alternative (Not PTCUtilities, I've heard that crashes, a lot) but I haven't the faintest idea how the qr codes are generated. Examining the source of PetitEditor is pointless, as it is quite messy and only slightly commented sometimes in japanese.

Anyways, Minesweeper source:
http://dl.dropbox.com/u/2808065/Caps/PTC/MINESWPR.png

Hey @GeekDude, instead of using recursion, you could use a makeshift queue. Just check the current cell for a mine, and if it's empty, place it at the head of some large array and keep track of the head/tail (the array only needs to be as large as the board). You could also keep track of which cells you've already placed in the queue with a couple of variables and bit-wise operators (just set bits to 1 in the variables to represent which cells have already been placed). Then have a regular loop which continuously checks the head of the queue, reads a 3X3 square around the head position, and places any empty squares that haven't already been in the queue at the tail. At the same time, you can count the mines when reading the 3X3 square and assign the proper number to the cell. Then just pop the head (increment the makeshift head "pointer") and repeat. I mean, it's not a general solution like making a stack to support recursion, but I'm guessing it might be easier. And although it may seem like it executes a lot, the upper bound is actually linear, so hooray!

Also, you can fake multi-line if statements by inverting the check and jumping to the end of a section of code you want to execute. It's not elegant, but it works wonders:

IF !(THIS WAS MY ORIGINAL CHECK) GOTO @NOTTHISIFSTATEMENT
'Now I can do a whole mess load of crap in here!
@NOTTHISIFSTATEMENT

Or, of course, you can write a "function" for every single if statement that needs multiple lines and call a GOSUB:

IF (CHECK) THEN GOSUB @MYIFSTATEMENT

...

(Somewhere near the bottom or something)
@MYIFSTATEMENT
'Blah blah blah
RETURN

Anyway, I really like your minesweeper program!

I thought about that, but then decided it was kind of gimmicky, and that I liked the gosub solution better.

Thank you

Also, my string stack solution doesn't work if you have to clear out too many spaces, it gets a string length limit error.

@GeekDude Dude, it's old-school BASIC. It's always going to be gimmicky in this day and age lol, just use it if it makes life easier (which it does). I must have used it almost a hundred times in this one program I'm writing, and although it's kind of interesting to come up with new label names every time, it's not like I'm going to run out of them (you get well above sextillion combinations of letters and numbers lol). If you indent properly, it starts to look like a real IF statement too!

Edit: Also, arrays can store much more data than strings, and although you don't get any of the cool functions for them, I generally like to use arrays for large data structures. But you probably already know this, so I'm sorry!

@randomouscrap98 I'm a bit confused why there is a for/next, but not an if/endif. Anyways, I'm sure I can use fake inline if statements when I feel it better suits the code.

Yeah, that was kind of silly. I kind of think it was just to keep it as "retro" as possible, but ugh... (many of the original dialects of BASIC didn't have an "endif" or anything).