Making a PTC Compiler

Have fun with palettes!

New commands to SB should for the most part be compiled as normal code, I think. Because it adds functionality while not being intrusive. If you want it to be a TRUE PTC compiler, then yeah, syntax errors. As for the processing between commands, I think that you should maybe have it as a compiling option (like OPTION STRICT)

Replace SB stuff with more PTC-like things. For example, STX and STY instead of STICK OUT... and most OUT commands would become RGBREAD(color),r,g,b (I think PTC did this with stuff like SPREAD)

So since N# Beta 1.7 has been released, MYCRAFTisbest convinced me to make a PTC compiler between updates. However, there are a couple of design options I'd like for you guys to help me decide on. *Should I do some extra processing between commands to bog down the speed of execution to PTC speeds? *Should I attempt to regulate the max value to the ~500,000 point? *Should it be more of a PTC compiler or backwards-compatible SB compiler? In essence, should new commands to SB (DEF, WHILE, REPEAT) trigger syntax errors or compile as normal code? *SmileTool or IDE? If I have more questions, I'll post them. Thanks in advance!

Don't bog it down, the main PTC problem I had was lag. Plus VSYNC takes care of that anyways) Just make an 'enhanced PTC' or something :D like bringing back useful functions but also letting you use some new stuff. Not replacements of old with new, but if it was new/old exclusive use it.

and also have fun with the font SB's text system is SERIOUSLY F***ED UP PTC used normal extended ascii.

and also have fun with the font SB's text system is SERIOUSLY F***ED UP PTC used normal extended ascii.

Fonts, palettes, and BGU stuff would be the hardest to deal with.

Yea, so far my main obstacle is palettes...I may need somebody to help me on that since I have no palette experience... I've decided I'll make SB-exclusive stuff trigger RUNTIME SYNTAX ERRORS (to match the frustration of PTC). I will not bog down execution speeds though. I also think I'll do a SmileTool. I'm still unsure of the max number thing (I may do OPTION stuff).

Yea, so far my main obstacle is palettes...I may need somebody to help me on that since I have no palette experience... I've decided I'll make SB-exclusive stuff trigger RUNTIME SYNTAX ERRORS (to match the frustration of PTC). I will not bog down execution speeds though. I also think I'll do a SmileTool. I'm still unsure of the max number thing (I may do OPTION stuff).

Max/min numbers: 524287 and -524288 The main problem would be finding a good way to check values.

Remember to limit lines to 100 characters! For the palette, try a 16x16 array…

You know how the palettes work? I can explain them to you. Sprites and bg basically worked the same, a COL file (PTC's palette file format) had a 16*16 grid of colors that could be used, each individual color had the standard 0-256 rgb format, every individual bg tile could use only one row of that palette at once, and each sprite could only use one row as well. You had to define which row would be used when you set the sprite/tile. You could load 3 palettes at once, one for sprites, one for sprites and the other for the graphics page. The graphics page worked similar but you weren't restricted to a single row, you could use any color at any time (edit it still had to be on the palette though). I prefered working with graphics over anything else but most often it was the slowest way to draw things on the screen. I remember when discostew made me a pal to col converter, I lost it several times and had to keep asking him to send it to me again. I probably got him to question the way he was spending his time helping me. :P Also I may have deleted my topic but I am still working on that interpreter if you saw it. I just needed someone to go over my code because a huge bug was just messing with the whole thing and it was out of my scope to fix it, but once I have something worth sharing I'll make a resource and all that.

Just ran som tests with PTC. BTRIG() is equivalent to BUTTON(2), heh. We had no reason to have it so they took it out. Compiler could just switch the two and it would be the same.

Palettes would be very hard. In fact, the entire CHR graphic bank system would have to be reimplemented, which might not be possible...

Palettes would be very hard. In fact, the entire CHR graphic bank system would have to be reimplemented, which might not be possible...

It'd probably just be really unoptimized.

I can think of a fairly optimized way to handle the BGs with palettes. You can cache the entire display state of a BG in a GRP (since 64x64 tiles is 512x512 pixels). Whenever BGPUT is executed, use GLOAD with the palette option to update the proper portion of the GRP. Other operations like updating a CHR or a palette color may force a full or selective redraw, as well. There are several ways to go about rendering the BG into the frame, such as using GCOPY with transparency or using a BG with 128x128 tiles mapped to the contents of the GRP four times (to support the wrapping behavior), though unfortunately the BG option will only work for one of the emulated BGs because you can only have one BGPAGE.

We were talking in the chat and decided our best option may just be to have the compiler ignore any commands concerning palettes and allow the user to use the whole RGB grid at once (attribute it to "hardware improvements.") Anyway, work is coming along great. I just added PNLTYPE and PNLSTR (ezpz) and BTRIG won't take more than 20 seconds.

So this will be much harder than I anticipated. There are two reasons I say this: 1) The massive amount of commands/functions I have to go through and reprogram. 2) Optional arguments I won't stop going, of course. I'll just need people with the modem working to import PTC programs and test them for me as I go. So, I suppose I'm requesting beta testers? I'd prefer experienced PTC users for this. Don't tell me your email; I'll send you a message via the site if you're accepted (and to send you keys).

We were talking in the chat and decided our best option may just be to have the compiler ignore any commands concerning palettes and allow the user to use the whole RGB grid at once (attribute it to "hardware improvements.") Anyway, work is coming along great. I just added PNLTYPE and PNLSTR (ezpz) and BTRIG won't take more than 20 seconds.

Without palettes, a lot of programs will break. How do you plan on changing from palette to all colors...?

So this will be much harder than I anticipated. There are two reasons I say this: 1) The massive amount of commands/functions I have to go through and reprogram. 2) Optional arguments I won't stop going, of course. I'll just need people with the modem working to import PTC programs and test them for me as I go. So, I suppose I'm requesting beta testers? I'd prefer experienced PTC users for this. Don't tell me your email; I'll send you a message via the site if you're accepted (and to send you keys).

What do you mean by experienced? I used PTC for a long time, but was kind of an amateur for most of my programming time :P I understood most of the commands, does that count as 'experienced' or do you want someone with a really deep understanding of pretty much everything in Petit? Also, do you plan on/how would you implement SENDFILE and RECVFILE?

I assume that SENDFILE and RECVFILE could be implemented using the local multiplayer functionality. I also wonder what you're planning to do about palettes. Though at least for graphics commands you can probably insert an array lookup for setting the color values, even if the graphics screen won't automatically change if the palettes change.

I assume that SENDFILE and RECVFILE could be implemented using the local multiplayer functionality. I also wonder what you're planning to do about palettes. Though at least for graphics commands you can probably insert an array lookup for setting the color values, even if the graphics screen won't automatically change if the palettes change.

Yeah, then they'd be slower though, wouldn't they. Does anyone know the max string size? If it was big enough to send with multiple lines, then SENDFILE stuff would be faster.