Homebrew Petit Computer Thread

[Snailface]

2 dim 3690
1 dim 4162

Well at least you don't have to rewrite anything now.

Anything else, just let me know, I follow this thread religiously.

 

[BassAceGold]

2 dim 3690
1 dim 4162

Well at least you don't have to rewrite anything now.

Anything else, just let me know, I follow this thread religiously.

The interpreter probably optimizes 2d array access to 1d, and if it doesn't, doing so yourself is just adding more parameters for it to parse. Seemed like a good idea.

 

[DiscostewSM]

2 dim 3690
1 dim 4162

Well at least you don't have to rewrite anything now.

Anything else, just let me know, I follow this thread religiously.

Actually, could you make a change to the 1-dim for me?

...

FOR Y=0TO MAXY-1
PY=Y*MAXX
FOR X=0TO MAXX-1
VALUE=MYARRAY(X+PY)
NEXT
NEXT
...

It does the exact same thing as before, except it moves that multiplication outside the inner loop (since that result is the same until the inner loop ends)

 

[Snailface]

The result 3538
That's really impressive for the 1 dim because its doing extra math (and parsing) unlike the 2 dim.
Guess you do have some rewriting to do after all.

Another optimization: change the MAXX-1 and MAXY-1 to 99 (that's what they are, right?)
result 2982

 

[DiscostewSM]

The result 3538
That's really impressive for the 1 dim because its doing extra math (and parsing) unlike the 2 dim.
Guess you do have some rewriting to do after all.

Another optimization: change the MAXX-1 and MAXY-1 to 99 (that's what they are, right?)
result 2982

I'm sure it is because of that additional arithmetic operation that is checked each time it loops, so I wonder if making a temporary variable that holds those max-1 would give a similar result as using a static value? Should also check what the 2-dim code would result in without that additional -1 operation.

Now, here's another optimization. Instead of making an assignment that multiplies by the "width" each time around, why not integrate that into the outer FOR statement? It already had to do a STEP1 before, so what about a STEP MAXX?

XE=MAXX-1
YE=(MAXX*MAXY)-1
FOR Y=0TO YE STEP MAXX
FOR X=0TO XE
VALUE=MYARRAY(X+Y)
NEXT
NEXT

 

[Snailface]

3123

I think its faster to use literals. Less parsing, less fetching.

I tried it with literals substituted everywhere and the result is 2951. A little faster.

 

[DiscostewSM]

True that using literals is faster, but the operations become locked to that literal when they are used, whereas a variable can be changed.

 

[Snailface]

Ok, I guess then just use literals wherever you can.

Also, the @main loop substituted with a FOR loop improves the time a little, 2929 vs. 2951.

BTW- somebody ported PitMan (the original inspiration for Catrap). It's really good.
http://www.spoonybar...tman/index.html

 

[DiscostewSM]

I just had a realization. Can't hold SAVE data in a single MEM file (which is 256 characters) and are not using the graphics (GRP) stuff? Then, use those as SAVE data. It's just data, right? Instead of a 256-byte limitation, you increase it to 49152 bytes. You just have a different way of writing/reading that data.

Also, did I completely forget that integer division can be done with Petitcom via '\'? (which differs from regular division via '/') Integer division is like regular division, except it throws out the fractional part. That in itself would reduce my code by so many levels, as I have been using FLOOR(X/Y) in so many places when I could just do X\Y instead, plus having to deal with fractional numbers (even if in fixed-point format) has to do extra calculations to maintain the format, so even less processing would occur imo.

 

[ejamer]

...
Also, did I completely forget that integer division can be done with Petitcom via '\'?
...

Nope, this doesn't work. Not in the manual, and throws a syntax error when I tried anyway.
Was definitely worth a try though.

 

[DiscostewSM]

...
Also, did I completely forget that integer division can be done with Petitcom via '\'?
...

Nope, this doesn't work. Not in the manual, and throws a syntax error when I tried anyway.
Was definitely worth a try though.

That's rather unfortunate, considering it is part of the actual BASIC language.

 

[BenRK]

Yeah... I've asked other programmers their take on this version of BASIC, and I've got a rather... "meh..." response.

 

[DiscostewSM]

Yeah... I've asked other programmers their take on this version of BASIC, and I've got a rather... "meh..." response.

Compared to what other versions?

 

[Snailface]

Yeah... I've asked other programmers their take on this version of BASIC, and I've got a rather... "meh..." response.

BASIC in general gets a meh response from programmers. It encourages spaghetti-coding, global vars, and has all-together slow performance.

However, this case is special. SmileBasic has a pretty good library, is easy to get into, fun, and not many other apps that I know of can brag about being "an SDK in a pocket". Anybody who wants to dispute the validity of Petit should only look at the amazing output of Japanese coders to remind themselves that this is to be taken seriously. If you can't make a damn good game with Petit Computer, its your own fault.

BTW- Disco, there is a little bit of a hacky solution to the integer division problem, but you can do this ICONPMAX=A/B and it will automatically floor the result. Its pretty fast but I don't know how much faster it is if you have to do an extra variable assignment. You can't use negative numbers either.

ICONPMAX is a little-known writable system variable btw. Mind as well make use of it. ^^

 

[BenRK]

Actually, that whole "Meh for all versions of BASIC" would explain the reactions I'm getting.

 

[DiscostewSM]

BASIC in of itself is pretty meh because of its performance and limits when you compare it to other languages. But, I'd like to think of it as a challenge, as many would push it to the side without even trying because they believe it can't do what they want it to do. That has been opposite to my mindset when attempting my Megaman 2 port. I took the time to see how far I could get before I'd run into problems. Granted I almost gave up after hitting the 60fps process limit before I progressed far enough, but I at least made the attempt, and am still doing what I can.

One thing is for sure though. I've learned some interesting tricks by using BASIC, and when I get back into DS homebrew via libnds, I've got some experience to work with (and a lot more processing power).

 

[BenRK]

So, has anyone found a way to import tilesets edited appropriately on a computer? Moving everything over pixel by pixel has been the biggest reason why I've put petit computer down the most.

 

[DiscostewSM]

Sorry for asking all these questions. I should get my 3DS back by the end of Tuesday.

I've noticed many programs made by others have compacted their code into as few lines by combining them with ":". However, does this impact performance, and if so, is it negative or positive? Would be nice if it was positive.

BTW- Disco, there is a little bit of a hacky solution to the integer division problem, but you can do this ICONPMAX=A/B and it will automatically floor the result. Its pretty fast but I don't know how much faster it is if you have to do an extra variable assignment. You can't use negative numbers either.

ICONPMAX is a little-known writable system variable btw. Mind as well make use of it. ^^

I guess it would depend on how much time it takes to insert into ICONPMAX and then to another variable vs using just FLOOR. I get the feeling that FLOOR would still be the better option due to less parsing.

So, has anyone found a way to import tilesets edited appropriately on a computer? Moving everything over pixel by pixel has been the biggest reason why I've put petit computer down the most.

Before you asked this question, I thought that the importing feature of PTCUtilities for anything other than actual PTC/GRP/etc files was broken, but after seeing videos of people doing it successfully, I had to investigate. It seems, being a man and all, that I didn't follow "all" the instructions when I originally downloaded the tools. It made reference to needing Quicktime (which I hadn't done but the program ran fine for what I needed at the time), so I installed it, and now importing images works. You can then create QR codes to import to Petitcom.

When you import to PTCUtilities, understand that any and all tiles in a CHR are limited to 16 colors (15 actually because of the transparency), so importing a 256-color tileset may have side effects unless you've organized the actual image correctly. How to do that, I don't know, but I think many people who had imported images also used GIMP, so that may help.

 

[BenRK]

I was unaware of PCTUtilities. That may help me out quite a bit.

 

[DiscostewSM]

I was unaware of PCTUtilities. That may help me out quite a bit.

It basically allows you to do everything you could with Petitcom's built-in programs like making graphics, coding, etc, except it can do more (like importing tilesets). Be aware of some bugs though. Main one I've encountered involves pasting code, which I believe can be avoided in two ways. First is one I found out by shrinking the code window to display only one code line and pasting in. The other that I read up involves adding a space to where you plan to paste before actually pasting (haven't confirmed it working yet). Another bug involves tileset (CHR) editing. If you try to draw below the lower and right limits, the program crashes.