Forums

Topic: Petit Computer

Posts 2,781 to 2,800 of 9,620

Hairmanban19

@Bigdog00 wanted me to tell you guys that he is going to update CincOS one more time.

...

3DS Friend Code: 3136-7615-5907

randomous

I'm sure this is already known, but I wanted to share it anyway.

I've been doing a lot of testing to see just how Petit Computer handles certain things in terms of speed (because my village game is slowing down when I'm trying to get more than 6 fish to swim around). For instance, if I execute something a bajillion times, what slows down the program the most? If you've taken courses in computer architecture and computer programming (or just know some stuff about it), you probably know about some of the basic things that cause slowdowns, such as mispredicted branches, stalling due to memory, etc. However, this is an interpreted language, so the things that slow us down are a little different. Let's take a look:

I tested the instructions that I thought would have the most performance impact first (since they do in other forms of BASIC), which were the "interrupt" instructions GOSUB and GOTO. I found that although these two instructions do incur a constant overhead, the size of the function you're jumping to and the distance to the function have no impact on performance whatsoever. The cost is extremely negligible too, at only about 1/1000 of a frame for each call to GOSUB (meaning you could call a thousand empty GOSUBs each vsync). The thing that struck me the most was that the distance to the destination of the GOSUB or GOTO has absolutely no impact. I guess Petit Computer quickly preparses your program and gets the exact jump destination so it doesn't have to search for it every time (I know some forms of BASIC actually DO search for it).

Next I tested the "heavy" operators, which are division, multiplication, and modulus. Amazingly, multiplication and modulus ran at exactly the same speed as addition and subtraction, meaning that Petit Computer probably makes sure that they all take the same amount of time. They all take about 1/5000 of a frame. Division takes slightly longer, but it's not by much (10-20%). Now about AND and OR... they actually take longer to execute than addition and subtraction! What??? So my next test was code size.

I figured code size would have some performance impact (because BASIC is interpreted and it needs to read every single character of code every time it wants to execute), but I tested it just to see. The results are unfavorable: comments and empty lines can actually increase execution time by a considerable amount! A SINGLE empty line costs around 1/10000 of a frame, which may not seem like much, but ten empty lines is about the same as a jump into a function. This is silly, I want my empty lines so I can format my program! At least comments are about the same: each comment costs 1/10000 of a frame, no matter how long it is. However, you also incur the cost of the new line, so be careful. A comment is then about 1/5000 of a frame if it is the only thing on the line. Here's an interesting thing to note: spaces just don't seem to count at all. So indentation is perfectly acceptable, but if you have empty lines, the DSi goes OMG I NEED TO PROCESS! The lesson: mash up as many lines as you can into a single one if you're grasping for speed.

This next one follows pretty logically from the previous, but variable names also impact performance, but much less than a new line. Each character in a name is about a quarter of a new line, so 1/40000 of a frame. But, if you're trying to cram as much as you can into a line, then shorter names might be better anyway (even if they're harder to understand).

So it also turns out that assignments are as expensive as GOTOs/GOSUBs, coming it at around 1/1000 of a frame as well. This means that having an assignment to get rid of some operations is only useful if the assignment gets rid of 5 operations (since each operation is 1/5000).

Well here's a pleasant surprise! COS and other trigonometric stuff is only twice as expensive as addition (1/2500 of a frame)! That's nice, considering I rewrote large portions of my code to reduce the number of cosine functions I called. Oh well. FLOOR is about 1.5 times as expensive as addition, which is about 1/3333 of a frame.


Well, it seems like the lesson here is get your program done with the least amount of code/assignments/operations as you can. For instance, don't try to improve your speed by replacing a modulus (power of 2) with an AND (power of 2 - 1), because although the latter is usually faster, in this form of BASIC the single operation [modulus] is actually faster than the two operations [AND and subtraction]. Don't have empty lines and long variable names unless you're not stressed for speed and want to be clear. Don't be afraid to use GOSUB/GOTO which are sometimes expensive in other BASICs. Well, sorry for rambling and taking up forum space with a bunch of pretty useless stuff. Hope someone gets a use out of this!

Edited on by randomous

randomous

Discostew

@randomouscrap98 - Wow, thanks for doing these tests. I'm actually surprised by some of your findings, particularly the modulos operation. I assumed maybe the speed increase was because it was a single character "%" vs 3 in "AND", but the actual operation of modulos returns the remainder of a division operation between 2 numbers. This I found odd because it has to divide to get the remainder, but it is faster than divide in itself. However, now that I think about it, the remainder is always an integer, whereas the division operation returns a float/fixed-point value. Internally, everything is an integer, and fixed-point is simply an integer that is shifted to allow extra values to form the decimal while at the expense of a smaller whole number ceiling.

But, seeing that modulos is faster than AND, I think I can greatly benefit from this information, so thank you again.

Just for reference, while FLOOR truncates the decimal portion of a value, so does 0OR (or 0 OR) due to the nature of logical operators working only with integer values, so it converts the right-most to an integer before proceeding. So, think you could test to see if 0OR is faster than FLOOR? FLOOR requires parenthesis, while 0OR does not (only needs a space to separate the operation and variable). In either case, 0OR requires in many cases 4 less characters.

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

randomous

@Discostew I'm glad you found it useful! After running numerous tests, it appears as if 0 OR (or 0OR if you want to mash it up) runs at exactly the same speed as FLOOR() with only the smallest amount of frames (a couple ten thousandths of a frame), which leads me to believe that the implementation of FLOOR is either an OR with 0 or a simple right shift (which should technically be just as fast as an OR), so either way is good.

randomous

TexMurphy

Question.
If I use CHRED or scan someone elses sprites will I loose the preset sprites that came with petit computer? Can I get them back if I do overright them?

TexMurphy

randomous

@TexMurphy You can never lose anything that comes with Petit Computer (sprites, programs, etc.). Think of that stuff as the floor, you can put a carpet on it, but the floor doesn't disappear. It just says "hey, you're looking at something else now". Same goes for colors: you can change them all you want, but as soon as you go back to the main screen they'll just reset to their default state.

randomous

Discostew

TexMurphy wrote:

Question.
If I use CHRED or scan someone elses sprites will I loose the preset sprites that came with petit computer? Can I get them back if I do overright them?

By default when running a program through VIEW GALLERY, they will always start with the preset tiles, for both background and sprites. But, through edit mode, and after you make changes within your program, you can get the presets back by using CHRINIT. Example...

CHRINIT "BGU0" will revert slot 0 of the BG character sheet back to the default. You can use this for all slots of both background tiles (BGUx, where x ranges from 0 to 3) and sprite tiles (SPUx, where x ranges from 0 to 7).

Edited on by Discostew

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

bigdog00

JOS will have an update, already added a new user account that goes straight to CincOS, one that goes straight to JOS, more apps for both CincOS and JOS (and JOS Classic). Also, https://plus.google.com/app/basic/stream/z12bshtrqkreipgcu23x... . That shows IM-Mail sending 2 attachments to my step brother. You can send anything, such as PRG: MEM: GRP: excetara. The rest you will just have to find out for yourself.

I like petit computer! Asphault 3d is awesome!

3DS Friend Code: 0473-8697-6288 | Twitter:

bmx7000

hi I am new to coding and I need help with sprites.
thanks in advance.

bmx7000

Pixelrobin

@everyone Heads up, I'm sending in my 3ds for repair (Luckly I still have the warranty). My L, R and B buttons quit working all of a sudden, The system thinks i'm holding down A when I press it, and the touch screen does not work for some applications such as Swapnote.

I was also wondering: Can I filter a GRP into one palette in a simple way? One part of my program needs to filter a loaded GRP into only the first color palette so it could then scan it and convert it into a background for pixel art editing. This way, you can convert any GRP file into pixel art.

@bmx7000 Search for the petit computer tutorial thread for that answer or check out youtube.com/petitprofessor for sprite tutorials and more.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

Discostew

@Bluerobin2

Not quite sure what you're asking, but a GRP simply holds an array of indices that refer to a 256 color palette (255 + 1 transparent), separate from it. Are you asking about how to quantize a GRP from 256 colors to 16 colors (15 + 1 transparent)?

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

randomous

Well that stinks... Petit Professor closed their account.

randomous

Discostew

@Bluerobin2

Well, I have three versions circulating in my head.

The first relies on the existing palette located in slot 0 of the GRP. Not the best palette, but a general purpose one nonetheless. Basically you examine all other colors, compare them to the 15 colors in it (color 0, no matter the color, is the transparency, so best not to compare with that), make a note for each of those colors which of the 15 it represents closest to, and then go through the entire image, and each time you find a color index that isn't part of the top 16, you use the reference you made just before, and set that pixel index to that new color.

The second relies on the 16 most used colors (the first being the very first color for transparency, so really only 15 colors to check) in the GRP, and assigning all other colors to whichever of the 16 chosen colors it fits with closest. It's good for images that already have a small palette set, but going from 256 colors to 16 might make for some bad output.

Versions three is based on the second version, but it optimizes the existing color palette to reduce the number of unique colors present prior to checking for the top 16 colors. There is what is known as the "web-safe" color palette, which consists of 216 colors, as each color component (red, green, and blue) have 6 variances (0x00, 0x33, 0x66, 0x99, 0xCC, 0xFF), so 6^3 = 216. By converting each color in the palette to this web-safe palette, you can then examine each color and remove any duplicates, resulting in an even smaller color palette. 6 component variances is just the start. You could go lower if needed. If each was 5 variances (0x00, 0x3F, 0x7F, 0xBF, 0xFF), the total number of colors would be 125. If 4 (0x00, 0x55, 0xAA, 0xFF), then 64 colors. If 3 (0x00, 0x7F, 0xFF), then 27. In either of these variances, you'd now have a new palette, and now you can go through the motions of the second version, select the top 15 colors, examine which color all the remaining colors best resemble, and then modify the image to use only the top colors.

I don't have any code for you right now, but give me some time to develop some, unless you're willing to give it a shot with how I described the different versions.

Edited on by Discostew

Discostew

3DS Friend Code: 4425-1477-0127 | Nintendo Network ID: Discostew

Pixelrobin

@Discostew I'll give it a shot. I just want my pixel art program as glitch-free as possible and since its reading a color on a GRP then setting a background in pixilated form, I want it to be able to read any GRP and convert it into pixel art.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

Sniper101

@bmx7000 Just to get you started on sprites... You can set a sprite using SPSET, it will be put in the upper left corner. You can change the default set position with SPHOME. SPOFS lets you move the sprite. SPSCALE lets you change the size (scale) of the sprite. You can also make your own sprites in CHRED but just stick to the BASICS, no pun intended, for now. These are some of the main commands for sprites. Play around with them and see what you can do.

Edited on by Sniper101

Sniper101

3DS Friend Code: 2208-4619-7423

bmx7000

@sniper101 thank you but i can set sprites and animate but when i use sphome it does not start where it should

Edited on by bmx7000

bmx7000

ramstrong

randomouscrap98 wrote:

Not that this has anything to do with anything else, but my plans for Village are on Windows sticky notes. How disorganized lol
When and if you do plan something, where do you usually do it?

When I plan on Petit Computer, I usually just use pen and paper. Lately, I have a composition notebook that I use as a journal. Usually, though, I just use the IDE as an outliner, doing top-down design right there on the editor and fill in the blanks, so to speak.

randomouscrap98 wrote:

I'm sure this is already known, but I wanted to share it anyway.

I've been doing a lot of testing to see just how Petit Computer handles certain things in terms of speed (because my village game is slowing down when I'm trying to get more than 6 fish to swim around). For instance, if I execute something a bajillion times, what slows down the program the most?

This is excellent resource, randomous. Do you mind reposting this on tutorial thread so it doesn't get lost?

randomouscrap98 wrote:

Well that stinks... Petit Professor closed their account.

That's strange. I wonder what happened? I had my YT account for months before I do anything to it and it doesn't get closed. I wonder if it has something to do with copyright issues. There was one about LP Content ID lately.

bmx7000 wrote:

@sniper101 thank you but i can set sprites and animate but when i use sphome it does not start where it should

I think the tutorial thread has better explanation than what people can come up spontaneously. Also, you're not the first person who has trouble with SPHOME. The question is, what kind of trouble? "Does not start where it should" begs the question "Where do you think it should?" Please describe the symptoms and expected behavior so other people can help you.

Edited on by ramstrong

Petit Computer Journal
Old site http://ramstrong.blogspot.com

Let's just call a spade, a spade.

3DS Friend Code: 1091-7596-4855

randomous

ramstrong wrote:

When I plan on Petit Computer, I usually just use pen and paper. Lately, I have a composition notebook that I use as a journal. Usually, though, I just use the IDE as an outliner, doing top-down design right there on the editor and fill in the blanks, so to speak.

That's cool, I didn't know PTC Utilities was so powerful.

ramstrong wrote:

This is excellent resource, randomous. Do you mind reposting this on tutorial thread so it doesn't get lost?

Sure, I can do that.

randomous

Please login or sign up to reply to this topic