Topic: Petit Computer

The colour isn't a requirement, contrary to what a lot of people think. The colour is optional. If not specified, it will go on the current colour (as set by COLOR; if not specified, white by default). So the actual syntax is:

PNLSTR X,Y,"My string to print"[,colour]

...i never said colour was a requirement, you're just being picky and correcting something that was already correct.
@Moorpheel i was thinking of doing something like that, but i'm not sure how i'm going to do it without 3000 lines of DATA :/

Huh, well you could save the rooms as series of attributes instead of "drawing" them in data yourself. Or literally drawing them in a graphic file and reading them there,

how can i get something to print on the touch screen. like if i use VISABLE 1,0,0,0,0,0 it makes the touch screen dark. but if i type ACLS:CLEAR in the programming it make the keyboard come up again. (witch is nice, don't get me wrong.) but i would like to have something print on the touch screen.

@Petitlife935 Use PNLTYPE "OFF" to turn off the keyboard. Then use PNLSTR to write to the bottom screen.

VISABLE would give you a syntax error

Yep. Use VISIBLE.

Thanks,

Stupid question this piece of code is giving me a type mismatch error:

Dim ExitData(3,4)
restore @area1
for k = 0 to 2
for l = 0 to 3
read ExitData(k,l)
next
next
data -1,-1,""
data -1,-1,""
data -1,-1,""
data -1,-1,""

Any assistance in this matter would be greatly appreciated.

Sincerely,

PTCRL

Other than the missing label @area1, when defining arrays with DIM, all elements are of the same type. You currently have it set for numerical. Strings are defined with a $ at the end of the name. Your data contains both numbers and strings, and the type mismatch involves reading a string into a numerical variable/array. You'll need to define a string array, and read into that string array after each 2 numbers into the numerical array.

say goodbye to the beloved next floor button
dungeon generation is (for the most part) fixed, and it chooses from a preset layout and randomizes the room sizes so it's not always the same.
i also have types and (some) moves done, with 21 animations so far. the damage calculator needs to be tweaked, one super effective move can do 200+ damage.
dialga and his sableyes got an enormous buff. dialga has 650 hp and 25 atk, sableyes have 30hp and 10 atk, and they all try to use the move that does the most damage. coughroaroftimespamcough
i'm going to finish two more pokemon and add some more moves and finish items, and then i'll release a new demu

@twinArmageddons Oh hey! I'm working on a randomized rpg too! Anyone remember Battlewoods? I've finally made up my mind about what its going to be. Seriousy, I re-wrote the game over 10 times . Maybe we could collab?

hmm... a collab would be interesting.
but i already have so much done >.<
maybe if you can convince me to do it

Wellll, my game isnt turn-based. Its like Zelda. So I can't really convice you. My idea for a concept was that the end of the game is reachable from where you start (your home island) But you have the option to go to other islands by typing their names (seeds!) and getting prepared for the final battle. I did want to make fighting bosses and bigger enemies turn based though. So touching them would take you to a seprate screen where you have more room to fight on a grid.

ah okay, if you need help with the boss fights feel free to use my code if you want.

Simple question (i know this will sound bad)
How many one byte values can a GRP hold (assuming one byte is from 0-FF ) or 0-255.
Thanks. I need to see how feasible it is to save my zelda maps in grp files.

Are there any required fields of math required for making better games like platformers and rpgs with collision and scrolling maps?

A single GRP can hold 256x192 8-bit pixels, so 49,152 bytes.

So basically I can have 256X192 tiles per GRP file.
Gotcha.
So I'd ideally need 2-3 GRP files for a zelda map thats 500 tiles by 500 tiles.
Yes?

If byte for tile, you'd need 6 GRPs (5.08 GRPs technically) for holding a map that is 500x500 tiles. If these are 8x8-pixel tiles, and the tiles could be constructed into 16x16-pixel tiles and still under 256 unique meta tiles, you can technically reduce the footprint to about 1/4 the size, so including the data needed to construct the meta tiles, you could fit into 2 GRPs. Then there's the possibility that you'd want to reduce this even further by incorporating compression. Depending on the complexity, you could possibly even hold an entire 500x500 tile (technically 250x250 metaltile) map within 1 GRP.

I currently use a special form of RLE for my compressed data (1 for graphics, 1 for levels). I'm thinking of looking into LZS/LZSS compression. I've dealt with it before when taking FF7 levels, decompressing them, and displaying them on the DS (not with PTC, but homebrew tools), but that was with C, and with memory pointers, whereas this is with BASIC and no memory pointers.

The higher level maths you can understand, the easier it is to comprehend. But in the end, programming is just logic. It's very similar to speaking a language. There's complex sentence structure, grammatical rules, and all that good stuff. All you need is an eager mind and you'll learn