Updated!

Here is a little project that I created during the restless hours of the night.
It will take a series of 3 pics and automatically render them into 4 new pics which can be used to create flickerless 4 level grayscale in Basic.

Since the pictures are only XORed onto the screen, text, sprites, and pretty much anything can be displayed without being overwritten by the grayscale. While asm relies on the timing of interrupts to create grayscale, this method dithers the pictures in such a way that simple XORing them in order creates grayscale, thus eliminating the need to time the updates of the screen.

Thee code to create the 4 level GrayScale is simple:

real(3.pic1,3
Repeat Ans
real(3,pic2,3
real(3,pic3,3
real(3,pic4,3
End

Since the method is simple, it is fast enough to be used in Basic programs.
Creating the pics is simple as well.
The first layer represents the Black and White
The second layer represents the Dark Gray
And the third layer represents the Light Gray

I've attached some example pics that could be used to create the grayscale
And of course the GrayScale creator is attached as well.

Attachments:

• 1.bmp (18.05 KB)
• 2.bmp (18.05 KB)
• 3.bmp (18.05 KB)
• final.bmp (18.05 KB)
• GRAYEDIT.8xp (1.71 KB)

Thanks! And Congrats to the other featured programs as well!
I hope in the future there will be more contestants.
I will also be putting forth my best effort  to improve upon previous standards.
May the years that follow be laden with innovation and ingenuity.

I noticed that there weren't any announcements so I decided to make one.

Welcome to the temporary forums!

I've made some minor changes to the program.

The program clears the keypress buffer after selecting a picture so that the first loops in paste/load/duplicate are not bypassed.

Added a few error messages dealing with memory and missing files.

Fixed a little glitch when importing external mods.
(The program didn't overwrite the graphscreen with the current pic prior to executing the mod)

All mods now have the ability to return back to Implicit without activating the affirmation message by returning 0 for 'no' (any other constant number will be assumed as 'yes')

In order to run the main menu of Implicit without getting a memory error, you must have at least 6580 bytes of RAM available. Only 4000 of the bytes are actually used, but almost of them are needed during the unpacking of the subprograms.

Things I might consider:
Using xLIB to check if Celtic2 exists, otherwise an error is returned.
(I'm still considering the benefits over the memory usage of this feature)

I'm also considering making all text uppercase in order to reduce the memory usage.

I might consider release a no eye candy version where all the unessential xLIB shape commands are removed. This will probably reduce the size of the program by 2000 bytes I'm guessing, however, this won't significantly reduce the amount of RAM needed since the 2000 bytes is spread out across the 8 different programs in the AppVar.

Problems that I am aware of:
In order to prevent memory errors, I have the sprite layers loaded at 16x16 even in 8x8 mode. This is so that the memory doesn't run out if the user were to switch to 16x16 mode with insufficient RAM. By doing this, 2315x3 = 6954 bytes of memory are used just on the sprite layers (2 active layers and 1 swap layer for doing operations such as rotate). So if you are ever wondering why the sprite editor uses so much RAM, this is why. I'll see if I can come up with a memory checking routine so that the sprite layers can be loaded based on the settings instead of always loading them at the maximum setting.

So check out this latest compile and let me know what you think.
Your suggestions/comments are very much appreciated, without them, it is difficult to create a utility that will meet the needs of it's users.

Thanks,
nitacku

I think pure Basic is all that is needed.
There is even a way to do sprites, however, the language is a bit awkward and very slow.

The only thing I ever used the program language for was to create a series of drop-down menus to organize my cheat/answers program.

Cool!
I really like the names of the cities
Especially Nitaka.

I voted for SM68k because it kept my interest longer.
(well actually, I got an address error while playing Doom that forced me to pull all of the batteries. That kinda pushed the vote over to SM68k)