Homebrew Petit Computer Thread

[BenRK]

I wont be using it to import code or anything. I'm actually perfectly fine using the code editor on the DS it self, it's just the tileset stuff I can't deal with without a more... proper image editing program. More so one I'm used to.

 

[Snailface]

LoL

You can't have a new homebrew platform without some herpderp. It's tradition.
(QR's in the description)

 

[DiscostewSM]

LoL

You can't have a new homebrew platform without some herpderp. It's tradition.
(QR's in the description)
[media]http://www.youtube.c...h?v=xp9EFkbcPIc[/media]

It seems natural now that such a thing is going to happen.

Well, I got my 3DS back and am ready to test my additions. Not happy by the repairs though because it seems that the one repair that I described wasn't even touched (the Start button). I don't want to send it back immediately because I actually want to enjoy having it for once within these past couple of months, but I can't wait too long, or else they may describe the situation not being wear and tear but of misuse of the system.

 

[Snailface]

Official English .pdf manual released!
http://filetrip.net/nds-downloads/other-files/download-petit-computer-manual-pdf-f30609.html

 

[DiscostewSM]

Scanned a few Japanese sites involved with Petitcom, and I found out something rather interesting

FLOOR(I/60)

can be reduced to

0OR I/60

This is just a guess, but since binary operators can't work with floats/fixed-point, the value(s) are automatically converted to integers, and since the result is always the one that isn't 0 (or is if both are 0), it effectively rounds down the values.

EDIT:

This got me into a realization, that anything that does require an integer will will truncate the values to become integers (rounded down) for the operation. This includes not just binary operators, but also arrays. This also made me realize that everything will always be a fixed-point value when stored in a variable, meaning that even if the value is aligned as an integer, it isn't, and certain operations like even 1*2 which are shown as integers will be multiplied as fixed point values, which first have to be converted to that. That creates a decent amount of overhead, and is probably the main culprit in computation slowdown.

 

[BenRK]

Ok, abandoning that project. Lets go even simpler! Circles roaming around the screen!

Question, what all can be displayed on the touch screen? Can I display ANY custom sprites?

 

[DiscostewSM]

Ok, abandoning that project. Lets go even simpler! Circles roaming around the screen!

Question, what all can be displayed on the touch screen? Can I display ANY custom sprites?

From what I understand, the lower screen has a background color layer, graphics layer, 2 BG layers, a sprite layer, and a layer that the keyboard and panel components occupy. Relatively similar to the top screen in that aspect. Unfortunately, it comes with some restrictions, one of which is no custom sprites (meaning you can't load your own sprite CHR data into it). Custom BG CHR data, on the other hand, can be loaded onto the lower screen.

 

[BenRK]

Hmm... That may pose a problem for my idea. Hmm...

Perhaps I could mimic my own sprites by using lines and fills and all that? That would take a while, but as the game is simple, it shouldn't take forever like how my dungeon idea was going to take.

 

[DiscostewSM]

I was actually thinking. Do they prevent you from any writes to the sprite CHR region of the lower screen? If not, then you could try a method I developed for leaving no empty spaces with sprites/tiles. I load a CHR file into the 8th sprite region of the upper screen, and then use CHRREAD/CHRSET for copying that data into the earlier sprite sections (while making a mark as to where each loaded section begins so everything is offset correctly). If writes can be made to the lower screen sprite regions, then this method could work for you.

And now for a little code time. When working on my project and encountering the dreaded slowdown effect, my button inputs started to become unresponsive from anything that didn't use BUTTON(0), so, I formed my own versions of instantly pressed and recently released based off of BUTTON(0).

BOLD=BT
BT=BUTTON(0)
BTIP=BT AND (NOT BOLD)
BTIR=(BT XOR BOLD) AND (NOT BT)

BOLD is the old button state (that shouldn't be used for button presses. BT is the new state of BUTTON(0). BTIP is the state of buttons instantly pressed (equivalent to BUTTON[2]), and BTIR is the state of buttons just released (equiv to BUTTON[3]). Figured these might be needed at some point.

 

[Snailface]

Ok, this is what I've been working on for the last couple of weeks. Hope you guys find it useful.

Petit Computer Function Guide
A Petit Computer Reference document for all functions, commands, operators, etc. in the SmileBasic Language.

Features:
*Each of the 180 functions, commands, and operators are documented with parameter lists, descriptions, and source code examples.
*112 QR codes for the example's source codes. Only one-liners and Run-Mode only examples were omitted.
*One page .html doc with hyperlinks aplenty for convenient navigation.
*Written in plain English. No Googlish or any extremely complicated technical explanations.

Download
Anyway, as this was a massive project, I'm sure a few errors may have slipped by. So please let me know if you find any.

 

[TheSven]

Does anyone know where I can find a manual to this thing? I don't mean the one in the program, that just tells me what I can do but not how to do it.

I found a manual for download right here, http://www.petitcomputer.com/manual/

Oops, already posted. Forgive my noob-ness.

 

[Snailface]

Here's a couple more options for viewing this:
Website: http://snailfacia.zxq.net/ (its free hosting so I can't assure its permanence)
PDF download: http://www.mediafire...pbar384dup4wglq
Original offline html doc: http://filetrip.net/...-10-f30665.html

And yes, in case you're wondering, it is more in-depth than the official manual for functions, commands, etc.

Petit Computer Function Guide
A Petit Computer Reference document for all functions, commands, operators, etc. in the SmileBasic Language.

Features:
*Each of the 180 functions, commands, and operators are documented with parameter lists, descriptions, and source code examples.
*112 QR codes for the example's source codes. Only one-liners and Run-Mode only examples were omitted.
*One page .html doc with hyperlinks aplenty for convenient navigation.
*Written in plain English. No Googlish or any extremely complicated technical explanations.

 

[BenRK]

Hmm... any idea if there's a music composing program out there for petit? I have a couple other friends with various skills. I'm the "programmer", another guy is an artist, and the third guy is a musician. With our powers combined...

 

[TheSven]

Before I start, I should say that all of my BASIC experience consists of what I've taught myself in the last 48hrs. I'm just starting from the small simple stuff and looking to build my way up, one step at a time. Today I write a "hello world" program, and perhaps in a few months make sprites that move around on a background.

Here is my very fist program, a whopping 13 lines of code. I'm experimenting with print, input, beep, and color. I'd like to work next with IF THEN functions, however everything I've found about these functions is pretty vague, and the things I'm trying keep giving me illegal errors. Does anyone know of a good site that gives good excercises in BASIC that I can adapt to this Petit Computer version, or could anyone add a few lines to this program showing how to do some IF THEN functions? I'd like to ask the user to choose between a couple choices, ie. "Do you like cats? Y/N" That kind of thing.

I'm having issues uploading the QR code, more to follow later...

 

[DiscostewSM]

A little progress report on my Megaman 2 project. Lots of optimizations done, and speed is decent with a couple of objects on the screen. Other than Dr. Wily's 2nd stage, I'm also working on Metal Man's stage. The enemies of those two stages (excluding bosses) have most of their AI done, as well as collision with the background. Megaman can shoot now. Currently dealing with sprite-sprite collision using my hitbox design (used also for background collision), but it seems the Petitcom sprite collision functions aren't cooperating with my sprite engine design. Still no ETA on my public release.

 

[DiscostewSM]

During my coding of this project, I had been doing a lot of simple calculation, storing them, and using them multiple times later, but I wasn't aware of the cost in doing that when compared to just calculating without storing until now. I then began to examine just how much time it took to store a calculation, and so I built this small test program.

CLEAR
POSX=100
POSY=55
DIM ARRAY1(100)
DIM ARRAY2(100,100)
FS=MAINCNTL
FOR I=0 TO 30000
LX=POSX/16
LY=POSY/16
RESULT=ARRAY1(ARRAY2(LX,LY))
NEXT
PRINT MAINCNTL-FS
END

...and compared it to this...

CLEAR
POSX=100
POSY=55
DIM ARRAY1(100)
DIM ARRAY2(100,100)
FS=MAINCNTL
FOR I=0 TO 30000
RESULT=ARRAY1(ARRAY2(POSX/16,POSY/16))
NEXT
PRINT MAINCNTL-FS
END

The result was 221 for the former, and 159 for the latter, less being better. A difference of 62. Doesn't seem surprising since it is having to store and use in the former, but consider doing that same array line multiple times, with the former continuing to store the divide calculation into a variable only once, and the latter doing that calculation multiple times in a single iteration. The result?

2 array line calls: 321 vs 286: a diff of 35 in favor of the latter
3 array line calls: 418 vs 404: a diff of 14 in favor of the latter
4 array line calls: 509 vs 521: a diff of 12 in favor of the former


It took just over 3 calls of that array line before the store and use method was faster than recalculating. This is just for simple calculations. When dealing with calculation of more complexity, the former method of storing and using will obviously be better, but at that point, I'm not sure because it depends on the operators used.

EDIT:
My mistake. I did the "recalculate" code wrong, with only one of the 2 divides being used. Redid the tests, and now it takes less calls before the former becomes faster.


EDIT 2:
Does anyone know if the process times on GOTOs and GOSUBs are affected by the distance of the destinations?

EDIT 3:
Nvm. Seems that when using GOTO/GOSUB, it begins a search for the destination from the beginning of the program. So, in light of that, it is best that any section of time crucial code that is accessed by GOTO/GOSUB should around the beginning. Or, better yet, try to not use them if possible.

 

[Snailface]

A member of another forum, ChangeV (and DiscoStew, who was 1st a few pages back), has a clever solution to the small mem save file problem. He converts whatever data he needs (text, numbers, maps, etc) as off-screen pixels (on and unseen graphics page) and then saves them to a "GRP:filename" file. This way he can store 256*192 (49K) bytes in a single file. Much better than 256 bytes I'd say

Here are the demo QRs he shared for this technique:

 

[DiscostewSM]

Yep, I mentioned that kind of idea a couple pages back.

 

[Snailface]

Yep, I mentioned that kind of idea a couple pages back.

lol FailSnail. Oh well, no harm in repeating good info.

 

[DiscostewSM]

Current progress of my Petit Computer version of Megaman 2

[yt]c98ZCSYHVg8[/yt]
Still no QR code yet.