Ahh, code in a spoiler tag! The mortal enemy of Chrome users!

Wait, why are you going back to using programs? This isn't a problem inherent in the fact that level data is stored in appvars, it's a problem inherent in the fact that your main program is compiled as an application.

Quote from: cooliojazz on October 21, 2010, 08:44:37 pm

first, I notice "{P-7-X+1}->{Str9+X}" should be "{P-7-X}->{Str9+X}" since P-7 is the first entry, not P-6, which is what yyou got by adding 1 back at the end...

Youre right. I removed the mistakes from the code in the last post.
Here is a screenshot showing what happens if I output appvar names character by character with 4 pxl gaps.

Why do it character by character? Didn't you just have code for storing it and displaying it as a string?

Well I'm finding it pretty hard to make sense of the level loading and actual game code, so I haven't gotten around to optimizing that yet. The menu, however, I could understand and optimize. And although I don't exactly understand all the level loading code, I optimized everything before the line If A≠C or B, as well as doing something like you suggested to get rid of all the different level strings and just have two strings (one for appvars, one for programs) in which the level number changes. I also made a few other optimizations throughout the program in random places, but for the most part, everything after the If A≠C or B line is unoptimized.

As far as I know, everything still functions correctly. Please tell me if this is not the case! If anything doesn't work correctly any more, it would probably be the level loading code, as I couldn't actually test it because I don't have a level with which to test it!

Total savings so far: 865 bytes (89% original size).


Maybe I'll try optimizing the level editor next. If I can somehow manage to shave off like 2000 bytes it will fit in a program.

Sorry for the confusion, my last post was directed towards ASBAD_ALVIN, not you DJ.

Quote from: Runer112 on October 20, 2010, 02:08:43 pm

Yes, you can use the Pt-Mask() routine for masking monochrome sprites, but you didn't quite define the logic of how things are drawn correctly. You got how to draw white and transparent pixels correctly, but black pixels need to have their corresponding bit be on in both buffers, not just the front buffer. Having the bit on in just the front buffer was designed for gray, which turns the pixel on in the back buffer (not used in black and white displaying) but turns the pixel off in the front buffer.

Not true, runer.  If you use Dispgraph with no r at the end it does it with only black on the first buffer...

Take the following program for example:
.TEST
[FFFFFFFF00000000]→Pic1
[FFFF0000FFFF0000]
ClrDraw
DrawInv
Pt-Mask(0,0,Pic1)
DispGraph
Repeat getKey
End

That sprite has both bits set for the first two lines of data, only the first buffer bits set for the third and fourth lines, only the second buffer bits set for the fifth and sixth lines, and all of the bits unset for the seventh and eighth lines. You get the result displayed in the attached picture. The first two lines are black, because both bits are set in the sprite data, but when only the first buffer bit is set in the sprite (lines three and four), the result is white. This is because the Pt-Mask() command is doing what would be gray, which means the back buffer pixels are on but the front buffer pixels are off.

EDIT by DJ: post was messed up due to additional code tag at beginning. Fixed

EDIT by me: I think I might have fixed it first, in which case you would have been edit ninja'd

Now go make a raycaster in Axe

I think he means the javascript effect itself isn't working, he isn't trying to record it or aything.