@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?
If you see in the top-left, I changed the quality in-game to 1. It started at 4.
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.
@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!
@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.
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.
@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.
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.
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.
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.
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.
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
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.
I see that the link ALSO have info on 3D hardware. Very interesting read, indeed! Thank you for posting it. Rather technical, though. My brain is at max capacity just trying to understand what's going on.
@randomous
Yes, I did. That's why when I'm testing math operation, I use single letter variable and put it all in one line. Thank you for posting your tests.
@discostew
FOR I=0 TO 90000:A=(TEST):NEXT
where (TEST) = 6+3, 6-3, 6x3,6/3,COS(4),ATAN(6,3)
My theory is that PTC parse multiplication ahead of addition/subtraction for program running optimization.
@Swordx i probably won't be able to post the sprites today because my dad is using the computer that i've been using for today. And my SD card won't fit in my other computer.
@IamAPerson620
I found another overflow which sometimes occurs upon colliding with a wall while walking with it. There isnt much we could do, for the error is a result of PTC not being able to handle all those numbers. You might want to remember that PTC was created for the dsi, and needs to translate the BASIC code into native code.
I still have dreams of PTC3D and it being able to handle polygonal elements. That would be quite cool.
As of PTC, I'm generally not doing much on it as of now. I got back into Gamemaker. The C - similar code is like a breath of fresh air.
I still have dreams of PTC3D and it being able to handle polygonal elements. That would be quite cool.
As of PTC, I'm generally not doing much on it as of now. I got back into Gamemaker. The C - similar code is like a breath of fresh air.
I still prefer Processing.org to Gamemaker. You prefer Gamemaker to Processing?
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.
That was me. I knew I could do that, but I wanted more of a minecraft-creative-mode feel.
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.
@Swordx i probably won't be able to post the sprites today because my dad is using the computer that i've been using for today. And my SD card won't fit in my other computer.
No problem!
By the way, I won't be posting anymore videos for about a week. I'm going on vacation.
When are the ssb games going to be done cant wait. Will it be today
I think they will be posted this Monday.
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.
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.
That was me. I knew I could do that, but I wanted more of a minecraft-creative-mode feel.
Forums
Topic: Petit Computer
Posts 3,830 to 3,849 of 9,620
Please login or sign up to reply to this topic