Forums

Topic: Petit Computer

Posts 3,821 to 3,840 of 9,620

randomous

@Discostew Ahhh, OK. Did you read my post about how it seems the interpretation of the code makes a big time impact? Longer variable names actually increased the time more than doing multiple arithmetic operations, which all seem to be fixed to a certain time. There's no way doing 10,000 divisions would be only a single frame longer than doing 10,000 additions unless they leveled all the operations to make life "more consistent".

Of course, it could all be poppycock. I didn't really make a test plan or anything... I just sort of tested it.

Edited on by randomous

randomous

Discostew

@randomous Longer names take more time than operators? Hmm, that could be why my programs may be hitting the processing cap far too often, since I tend to name my variables a bit long in order to keep them unique. I knew it takes time to parse them, but to the point of taking longer than multiple arithmetic operations? That's something I didn't know. I generally program in c/c++ which does compiling, so I don't take notice in these things.

In general on the DS hardware, divides take much longer to process than additions do, but I would say the parsing/processing of variables and such that encompass them take much longer, resulting in the two operators not looking so distant in processing cycles overall.

Discostew

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

randomous

@Discostew Well, divides take longer on anything, even the newest Intel processors. But yeah, all the extra processing involved with interpretation plus whatever system they have in place to manage variables probably overshadows any arithmetic operation.

I'm going to run a more thorough test to see exactly how much names impact time compared to operations. In my initial test, I simply had L*L/3 compared with LONGNAME*LONGNAME/3 in a loop, and the latter took longer. I want to see just how much longer it takes. Also, empty lines take a considerable amount of time (for a line with no code, that is). For instance, this code:

FOR I=0 TO 99999
A[i]=FLOOR(I*3/4)
NEXT

Is faster than this code:

FOR I=0 TO 99999

A[i]=FLOOR(I*3/4)

NEXT

(with added empty lines)

But I don't remember by how much. I'll compile a list of examples and show their time differences.

I also like to use descriptive variable names, have lots of empty lines to show important code blocks, and comment every block. However, after my program was running sluggishly, I changed the long variable names in critical sections to 4 letters and assigned long, repeated operations (not simple ones, LONG ones) to 4 letter variables as well. Finally, after removing all empty lines and comments from the time-critical section of code, my code was about 1/4 of the size (in characters). Now, instead of only being able to process 6 fish per frame, I can process 10-12 if I wanted (I still don't just in case I want to add some other stuff to the fish frame). It's a good improvement, but I want to know exactly what causes the biggest slowdown, so that's why I want to do a thorough test.

Edited on by randomous

randomous

Slayer

I need the A button pressed for my game to run and I don't know the button code for A. Help, please!

I have nothing really to say about myself.

Slayer

I tried 0 and 1 already

I have nothing really to say about myself.

randomous

@slayer You read button presses with BUTTON(). The button codes are:
UP = 1
DOWN = 2
LEFT = 4
RIGHT = 8
A = 16
B = 32
X = 64
Y = 128
L = 256
R = 512
START = 1024

If you want to detect an A, just do:
B=BUTTON()
IF B == 16 THEN DO SOMETHING

If you want to allow A to be pressed simultaneously with other buttons, do
B=BUTTON()
IF B AND 16 THEN DO SOMETHING

@Discostew So this is what my more refined test showed:

FOR I=0 TO 9999
A(I)=FLOOR(I*4/3)
NEXT

Takes 32 frames

FOR ITERATOR=0 TO 9999
ARRAYNAME(ITERATOR)=FLOOR(ITERATOR*4/3)
NEXT

Takes 39 frames (An 81% increase in total characters gives a 21.9% increase in time!)

FOR I=0 TO 9999
'A comment yo!
A(I)=FLOOR(I*4/3)
NEXT

Takes 34 frames (a single comment gives a 6% increase. The length of the comment doesn't matter, only the #of lines)

FOR I=0 TO 9999

A(I)=FLOOR(I*4/3)

NEXT

Takes 37 frames (Adding 4 blank lines gives a 15.6% increase). Nintendo life doesn't show the blank lines. It's just the first loop with 4 empty lines.

Also, this is a pretty neat way to do 3D: http://www.youtube.com/watch?v=6HTxa8utgUA
Instead of trying to make it real time, they just did it more like the included RPG game on Petit Computer (it just looks much better). I know it's just kind of "stationary" 3D, but I thought it looked neat anyway.

Edited on by randomous

randomous

Pixelrobin

I too have played around with the raycast demo. I removed the jump feature since it was not needed, and removed the bottom screen camera control. In its place, I made left and right control the camera.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

InsertPi

Bluerobin2 wrote:

I too have played around with the raycast demo. I removed the jump feature since it was not needed, and removed the bottom screen camera control. In its place, I made left and right control the camera.

What I did is change the jump button to the X button, and change looking to L and R.

If Facebook, Myspace, Twitter, Instagram, and Snapchat were all destroyed, 90% of teens would go insane. If you're one of the 10% that would be laughing at them, copy & paste this into your signature and hope it happens.

3DS Friend Code: 2148-9259-0831 | Nintendo Network ID: IAmAPerson620 | Twitter:

Pixelrobin

@IamAPerson620
Nice! Did you port the minecraft block texture in yet? I'm working on adding a skybox. I'm not copying Minecraft, I'm just seeing how far I could go before The game is completely un-playable.

Everybody do a chirp. CHIRP.

3DS Friend Code: 3007-9228-5126

InsertPi

Bluerobin2 wrote:

@IamAPerson620
Nice! Did you port the minecraft block texture in yet? I'm working on adding a skybox. I'm not copying Minecraft, I'm just seeing how far I could go before The game is completely un-playable.

Yes. The game now shows a 16x16 brick texture without increasing the size of the blocks. Pictures?
Untitled
If you see in the top-left, I changed the quality in-game to 1. It started at 4.

Edited on by InsertPi

If Facebook, Myspace, Twitter, Instagram, and Snapchat were all destroyed, 90% of teens would go insane. If you're one of the 10% that would be laughing at them, copy & paste this into your signature and hope it happens.

3DS Friend Code: 2148-9259-0831 | Nintendo Network ID: IAmAPerson620 | Twitter:

Hairmanban19

IAmAPerson620 wrote:

@Hairmanban19 @AnyoneElseWhoCares I am "abandoning" Person Text RPG II. Sorry guys. School is starting soon, and as I will be a Freshman in high school, I will not have much time to program. Also, I am doing more with graphics than text. So today (the 2nd), I will post the QRs I have so far. If you would like to pick up where I left off, feel free to! All I ask for is credit for the intro and the Prologue thru Chapter 2 if unmodified. If you modify it, feel free to take some credit. You can take full credit for anything else. Thanks guys!

Nooooooooooooo!!!

...

3DS Friend Code: 3136-7615-5907

Hairmanban19

@Swordx i have made a couple cactus sprites and a couple plant sprites so far. When i have the time,do you want me to post the sprites here?

...

3DS Friend Code: 3136-7615-5907

InsertPi

@Bluerobin2 I have noticed a bug. If you dig your face into the corner of a block (walk up to the corner of a block, them move the camera left and right), the game recieves an overflow on line 98. I played around with the numbers a little bit, but can't seem to prevent the crash. I was wondering if you could fix the collision? I don't know how. Also, if you want, I can add /size <8 or 16> to toggle 8x8 or 16x16 textures.

If Facebook, Myspace, Twitter, Instagram, and Snapchat were all destroyed, 90% of teens would go insane. If you're one of the 10% that would be laughing at them, copy & paste this into your signature and hope it happens.

3DS Friend Code: 2148-9259-0831 | Nintendo Network ID: IAmAPerson620 | Twitter:

swordx

Hairmanban19 wrote:

@Swordx i have made a couple cactus sprites and a couple plant sprites so far. When i have the time,do you want me to post the sprites here?

Yes please.

swordx

ramstrong

Discostew wrote:

In general on the DS hardware, divides take much longer to process than additions do,

I think this is true on GBA hardware where division is done by software, as they don't have divide instruction on the CPU. Surely, DSi hardware would have hardware division by now.

I ran some tests, and addition and multiplication are 174,173 frames respectively. It seems that addition is longer than multiplication, although that could be the fact that I inserted a PRINT command there. Where as multiplication and division would be 173,184 respectively. It seems that division is only about 5% longer, hardly a concern, IMHO.

I did 90,000 divide operations, which translate to 30,000 divide per second, including FOR-NEXT. This was done on 3DS XL.
For fun, I also did COSine. It takes up 199 frames.

EDIT:
ADD 175,175,175,175,175
SUBTRACT 175,175,174,175,174
MULTIPLY 172,172,173,172,173
DIVIDE 202,184,184,184,184
COS 188,188,188,188,188
ATAN 223,224,224,224,224

I am having trouble believing that multiplication is faster than addition, but there it is! No idea how that DiV 202 got there, or COS 199 either.

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

Slayer

randomous wrote:

@slayer You read button presses with BUTTON(). The button codes are:
UP = 1
DOWN = 2
LEFT = 4
RIGHT = 8
A = 16
B = 32
X = 64
Y = 128
L = 256
R = 512
START = 1024

If you want to detect an A, just do:
B=BUTTON()
IF B == 16 THEN DO SOMETHING

If you want to allow A to be pressed simultaneously with other buttons, do
B=BUTTON()
IF B AND 16 THEN DO SOMETHING

@Discostew So this is what my more refined test showed:

FOR I=0 TO 9999
A(I)=FLOOR(I*4/3)
NEXT

Takes 32 frames

FOR ITERATOR=0 TO 9999
ARRAYNAME(ITERATOR)=FLOOR(ITERATOR*4/3)
NEXT

Takes 39 frames (An 81% increase in total characters gives a 21.9% increase in time!)

FOR I=0 TO 9999
'A comment yo!
A(I)=FLOOR(I*4/3)
NEXT

Takes 34 frames (a single comment gives a 6% increase. The length of the comment doesn't matter, only the #of lines)

FOR I=0 TO 9999

A(I)=FLOOR(I*4/3)

NEXT

Takes 37 frames (Adding 4 blank lines gives a 15.6% increase). Nintendo life doesn't show the blank lines. It's just the first loop with 4 empty lines.

Also, this is a pretty neat way to do 3D: http://www.youtube.com/watch?v=6HTxa8utgUA
Instead of trying to make it real time, they just did it more like the included RPG game on Petit Computer (it just looks much better). I know it's just kind of "stationary" 3D, but I thought it looked neat anyway.

Okay, I'll remember that. Thanks, the button pressing in Gladiators is being a problem and I suspected my button code was wrong.

I have nothing really to say about myself.

Discostew

ramstrong wrote:

Discostew wrote:

In general on the DS hardware, divides take much longer to process than additions do,

I think this is true on GBA hardware where division is done by software, as they don't have divide instruction on the CPU. Surely, DSi hardware would have hardware division by now.

I ran some tests, and addition and multiplication are 174,173 frames respectively. It seems that addition is longer than multiplication, although that could be the fact that I inserted a PRINT command there. Where as multiplication and division would be 173,184 respectively. It seems that division is only about 5% longer, hardly a concern, IMHO.

I did 90,000 divide operations, which translate to 30,000 divide per second, including FOR-NEXT. This was done on 3DS XL.
For fun, I also did COSine. It takes up 199 frames.

Yes, the GBA doesn't have a hardware divide, and starting with the DS, hardware divides (and square-root) were added to the memory mapped registers. But, at the machine code level, divides are still several times slower than addition/subtraction. It's the setup of parsing/interpreting with the PTC language that make up the bulk of any operation, making actual addition and divide commands seem instantaneous by comparison.

Just to note, an addition/subtraction operation can be done in a couple of cycles at most, whereas divides, even under hardware, still take at least 18 cycles to complete.

http://nocash.emubase.de/gbatek.htm#dsmaths

EDIT: Mind showing the example in code for the addition and multiplication? I might have a theory that explains it, but I need to see your test cases.

Edited on by Discostew

Discostew

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

ramstrong

Discostew wrote:

ramstrong wrote:

Discostew wrote:

In general on the DS hardware, divides take much longer to process than additions do,

I think this is true on GBA hardware where division is done by software, as they don't have divide instruction on the CPU. Surely, DSi hardware would have hardware division by now.

I ran some tests, and addition and multiplication are 174,173 frames respectively. It seems that addition is longer than multiplication, although that could be the fact that I inserted a PRINT command there. Where as multiplication and division would be 173,184 respectively. It seems that division is only about 5% longer, hardly a concern, IMHO.

I did 90,000 divide operations, which translate to 30,000 divide per second, including FOR-NEXT. This was done on 3DS XL.
For fun, I also did COSine. It takes up 199 frames.

Yes, the GBA doesn't have a hardware divide, and starting with the DS, hardware divides (and square-root) were added to the memory mapped registers. But, at the machine code level, divides are still several times slower than addition/subtraction. It's the setup of parsing/interpreting with the PTC language that make up the bulk of any operation, making actual addition and divide commands seem instantaneous by comparison.

Just to note, an addition/subtraction operation can be done in a couple of cycles at most, whereas divides, even under hardware, still take at least 18 cycles to complete.

http://nocash.emubase.de/gbatek.htm#dsmaths

Hmmm. Interesting.
Since we are using PTC, I guess we're stuck with the parsing and all. I wonder if we can ask SmileBoom to provide a BASIC compiler for us.

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

Let's just call a spade, a spade.

3DS Friend Code: 1091-7596-4855

Discostew

ramstrong wrote:

Discostew wrote:

ramstrong wrote:

Discostew wrote:

In general on the DS hardware, divides take much longer to process than additions do,

I think this is true on GBA hardware where division is done by software, as they don't have divide instruction on the CPU. Surely, DSi hardware would have hardware division by now.

I ran some tests, and addition and multiplication are 174,173 frames respectively. It seems that addition is longer than multiplication, although that could be the fact that I inserted a PRINT command there. Where as multiplication and division would be 173,184 respectively. It seems that division is only about 5% longer, hardly a concern, IMHO.

I did 90,000 divide operations, which translate to 30,000 divide per second, including FOR-NEXT. This was done on 3DS XL.
For fun, I also did COSine. It takes up 199 frames.

Yes, the GBA doesn't have a hardware divide, and starting with the DS, hardware divides (and square-root) were added to the memory mapped registers. But, at the machine code level, divides are still several times slower than addition/subtraction. It's the setup of parsing/interpreting with the PTC language that make up the bulk of any operation, making actual addition and divide commands seem instantaneous by comparison.

Just to note, an addition/subtraction operation can be done in a couple of cycles at most, whereas divides, even under hardware, still take at least 18 cycles to complete.

http://nocash.emubase.de/gbatek.htm#dsmaths

Hmmm. Interesting.
Since we are using PTC, I guess we're stuck with the parsing and all. I wonder if we can ask SmileBoom to provide a BASIC compiler for us.

You don't know how thrilled I'd be if they did that. Even if it was to remove the parsing but still had to interpret commands would increase processing capabilities several times over.

Discostew

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

Ralph

To the person here who was asking how to edit DATA ti change the map in that raycasting program just edit the mapdata array instead to add/remove blocks.

Ralph

Please login or sign up to reply to this topic