Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: nitacku on January 23, 2008, 05:47:00 am
-
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) (http://z3.ifrm.com/23/12/0/p6455/1.bmp)
- 2.bmp (18.05 KB) (http://z3.ifrm.com/23/12/0/p6456/2.bmp)
- 3.bmp (18.05 KB) (http://z3.ifrm.com/23/12/0/p6457/3.bmp)
- final.bmp (18.05 KB) (http://z3.ifrm.com/23/12/0/p6458/final.bmp)
- GRAYEDIT.8xp (1.71 KB) (http://z3.ifrm.com/23/12/0/p6459/GRAYEDIT.8xp)
-
Great work, this is about the same method I used in my (http://www.ticalc.org/archives/files/fileinfo/383/38387.html) 5 lvl GS demo. CDI also had made a 4 lvl GS demo (http://cdi.calcgames.org/gstut/BASIC%20Grayscale%20Using%20xLIB.htm), but is more effective than mine (less time consuming to show fewer colors). Kevin had made a GS game (http://www.ticalc.org/archives/files/fileinfo/384/38413.html) with xLIB (he also made it with omnicalc, which this (http://www.ticalc.org/archives/files/fileinfo/358/35823.html) tut is helpful), not to forget his Reuben (http://www.ticalc.org/archives/files/fileinfo/359/35900.html) games (http://www.ticalc.org/archives/files/fileinfo/362/36206.html)!. CDI also made a GS minesweeper, I hope you can make something wonderful from your demo!
-
wow this is great! IU ddint knew you would do it so fast! ANd I feel so stupid now, because I was sure the only way to do it was to create the scanlines pixel by pixel by detecting if its on or off in pic 1 and on or off in pic 2, but you separated all gs layers so its much easier and faster. :)
To be honest I think this technique is the most effective (altough memory hungry) because it only need to loop between 3 frames to achieve grayscale. In both CDI/kalan methods it had to go through 4 frames to achieve grayscale: In frame 1 lightgray was not displayed and darkgray was black, in frame 2 lightgray was displayed and dark gray as well. In frame 3 it was the same thing than frame 1 and in frame 4 it was the same than frame 2 but the checkered pattern was at a different location. This caused the grayscale to still flickers badly, and the contrast between light gray and dark gray were way too high. However this method was practical for 5 level grayscale, you just had to add a constantly moving and never dissapearing checkered pattern for middle gray.
In my method, it just XORs scanlines to make them move in a certain direction and since it go through 3 layers only it flicker less badly. You even have to slow it down on the 83+SE because it is so fast that it get out of sync with the slow LCD driver. Basically my method shows scanlines that are similar to the ones in Desolate and Lost Legends.
The only downsides of my method is that
-you need 4 pictures. The starting one can be deleted right after map display but dont forget to recreate it if you need to show text for example andwant to redisplay the screen for example
-Idk if kalan/cdi method do this too, but in mine, since it cycle through 3 XOR pics, make sure that at the end of your program loop the 1st layer is displayed, so it loops properly through them when the WHile/for loop of your game is finished.
-Sprites are a pain to make, because it's tricky to draw the scanlines properly. It's often trial and error and it can take one hour to draw one 8x8 tile. The shortest amount of time I took to make one by hand was 15 minutes. So this is why Nitacku wrote an automatic grayscale ditherer.
-
all i can say is nice, cuz I know gs is hard in basic
-
right now the hardest part is to make it switch layers at a constant speed. It is hard because some BASIC commands are way too fast so the LCD can't handle that many display changes in so small amount of time.
The best way is to have it show less layers per loops but then it look like crap on the regular 83+. The next way is to show more (like two every commands), but then the game is very slow on the 83+. If you make it go both fast and look nice on 83+ then it look like crap on the SE
-
(http://omnimaga.unitedti.org/mcoggrayscale.gif)
Emulators doesn't do justice
-
actually, I kinda like the color changes. it kinda looks as if it's glowing fire light or something. or glowing gold.
-
for a second i thought this was a lib so you can make it 4 level in a game....its still pretty sick tho
-
Yeah, the emulator really doesn't do a very good job with recreating the grayscale.
On a real calc, the grayscale is flickerless, at least it is on my 84+SE.
Seriously, try it out. The grayscale creator is really cool :P You'll like the results.
-
for a second i thought this was a lib so you can make it 4 level in a game....its still pretty sick tho
mhmm dinho actually it is. You can add this grayscale in game. In 2005 I had a demo of a 4 level grayscale walking engine (that did nothing but walking tho) using a similar method and it was pretty neat. I recommend to only use it in RPGs or puzzle games though
-
that could be a concept of a Nemesiat style game
(http://mtv-music-generator.com/uploads/photo-1.gif)
The problem is the bad looking HUD but it's because the original had ASCII sprites so map was 60px wide instead of 80, letting more space for the HUD
-
Nice!
I'm glad to see that someone is using my utility :D
If you would like, I can even program a sprite editor to make the process easier.
It probably wouldn't have real-time grayscale editing, but it would feature the automatic grayscale conversion so that you can preview the sprites whenever you want.
-
nah dont worry it should be ok. I do all my spriting on the PC anyway ^^
-
o.o those are nice sprites and tiles!
-
The program has been updated.
Check the first post for download.
The new version fixes a little bug that occurred in the last 4 columns of pixels.
Also, Swap and Delete functions were added to make editing pictures easier.
-
Hey Kevin, what calc did u emulate in the demo pic? Was it on the 83+ or the 83+ SE?
-
THis was on a regular 83+ because PindurTI only emulates the 82, 83 and 83+.
That said grayscale on WabbitEmu looks like grayscale on a TI-83+ that was downclocked to 1 MHz instead of 6 or worse, no matter the model emulated, which is why I have to stick to 83+ emulation for such things :(
I would try in TilEm but it stopped working since I have TiEmu GTK runtimes installed
-
I may be discontinuing my Nemesiat remake project, because the way i would like the map to look (see image attached to this post) will not work, because I have been spending about 3-40 hours trying to figure out an algorithm that could generate such tilemaps from a map stored into a picture, meant to only have two tiles at a time using this engine. This pic use 11 tiles for the map. The lil bush is meant to fill the space that is impossible to fill with the 10 other tiles, due to the way they are made. Such algorithm requiring to alternate from a tile to another and detecting if the tile above is walkonable or not, same for left/right/down, and only putting a bush if both above and lower or left and right tiles are walk onable, is way too much for my brain, even after trying to find it after 30 hours. I do not want to go 16x16 because I'm sure the tilemapper will kill the grayscale quality due to its slowness and I do not want to have sprites similar to ROL3 trees because they will look way too simple in grayscale and maps will be boring. I've tried to make good looking tree tiles in 8x8 grayscale and i failed. It never came out good. The only solution aside from the tilemap generator would be to convert the entire map into matrices manually but then it will defeat the point of my project to be as small as possible. I did calculations and all maps from Nemesiat together would make a total of 100 KB, compared to the current 3.8 KB
Unless someone can figure out how to make good looking 8x8 tree tiles (only the top of the tree) as well as good looking dungeon tiles or a better way to make the maps (which require no modifications of the map pictures) this project is dead.
Attachments:
- ghg.bmp (145.18 KB) (http://z3.ifrm.com/23/12/0/p7960/ghg.bmp)
-
Ill take a look see at it after work when i get home . Do you at least have some sample code?
-
o.o what's wrong w/ those tiles? I like them
and it sucks about TilEm, I think the dependencies are kind of stupid since GTK seems to change all the time.
-
its not the tiles look that are the problem, but I cannot use them in such tilemapper.
I think I may give 16x16 tilemapper a try again, but last tiem I tried the 8x8 one with a big map with scrolling grayscale and the scrolling killed the grayscale literally. Maybe 16x16 would be faster tho since there would be less tiles to be displayed at once on the screen
-
Well you could make a converter to transpose the levels into the format needed, it would be a real shame if you didn't complete such a great masterpiece! Those sprites look sick! (as in awesome :P)
-
well thats the problem, i spent 40 hours figuring out how to do that converter, and failed
-
Update: It seems the 16x16 tilemapper runs much faster than the 8x8 one. I guess it is probably due to the much lower amount of tiles being displayed on the screen at once. Since i could only do 16x16 gs tiles successfully, not 8x8 ones, I will have to rely on those 16x16 ones, and I will go with scrolling. The scrolling grayscale tilemapper quality is the equivalent of Reuben Quest walking engine, except that there is no quality drop while moving. It's only scrolling though. No collision detection, no walking engine. It seems to run pretty fast though (approx 8 frames per second), so hopefully maybe I could increase the quality at the cost of some speed. The sure thing is that the game will require a SE or a 84+ to run though, else either the grayscale will look bad or the game will be slow.
-
Very, nice. You should post the 8xk or a vid of how it looks atm. :)
-
nah it's not 8xk, it's 8xp + 8xi files. I will prbly post a video of it when i am done. Not a screenshot from PTI/wabbit because the grayscale looks ugly in those
-
Alright, that sounds good. I agree, BASIC grayscale doesnt look right on emus. :)
-
Can not wait to see this progress via SS :P (vid)
-
(http://omnimaga.unitedti.org/nemesiatgs1.gif) (http://omnimaga.unitedti.org/nemesiatgs2.gif) (http://omnimaga.unitedti.org/nemesiatgs3.gif)
-
OMG, that is some fast scrolling! Nice tiles too! O.o, I am in love ;)
-
xlib I assume... but it is looking very nice.
-
Oh wow, that looks magnificent! Also,What did you use to capture the ss?
-
PTI most likely it is the best for that kind of thing.
-
TheStorm doesn't seems too enthusiastic about seeing new BASIC (or specifically xLIB) project, but It doesn't matter much as Zetaboards has an ignore feature like IPB 2.x, which Invisionfree doesn't have, but thanks Art Of Camelot.
I used Calcapture to make the screenshot from PindurTI. I didn't used the built-in screenshooter because I needed the screenshot to go at the speed of SE/84+ calcs, which PTI doesn't support and I wanted the screenshot to be 2x size. Also grayscale looks like crap in other emulators
-
Ahh ok nice. I Can't wait to see more, it looks really fast.
-
On an offtopic note I wonder why does it matter so much to some people if a game is made with xLIB, with ASM or with BASIC? I still can't understand why in 2008 people still attempt at making others feel embarrassed or feel bad for using one of those and tries to discourage him from continuing his project? I just see no point about this. Imho those people should just keep their comments to themselves and not post in the topic if they don't like the game just because of the ressources used to make it. It is just retarded, elitist and stupid.
After that people wonder why I deleted my files from calcg.org and UTI (and soon ticalc.org too when their file archiver in charge of emails comes back)
-
ooh, lookin good!
-
OMG that looks even better than LL right now lol
edit:
@DJ_Omnimaga, I think it's because people need know if they can achieve the same thing themselves. If it's in ASM and they don't know ASM, they won't really care too much. If it's xlib and they do now ASM, it's more pressure to do something similar.
I have to say, xlib and celticI-III are a boon to the ti community. Seriously, way to Kevin. You can still out do some of the best.
-
Id agree that it matters but not in a bad way. Great looking tile kevin.
-
Progress on this might be delayed due to some recent events, and the fact my TI-83+SE appears to be nearing its death. When I put in new AAA batteries, even if the calc isn't used at all after two days the batteries are dead. No ASM programs were running and I was using 2nd+OFF to turn it off. Idk if it's because the lithium battery is dead, but it doesn't seems good, as IIRC the lithium battery was only in charge of keeping RAM intact when the calc batteries are changed and when I change them it still does. It could be a battery that is defect, but it did that with 2 sets of batteries so far, and I tried with two different brands (not mixed together of course).
Keep in mind the calc is 6 years old now, and the newer the stuff, the faster it tend to break *points to 1994 TVs that broke before his 1986 one*, so maybe this calc is about to be done. I cannot program this on my bro's 83+ because half of the stuff in this project required a SE to run
EDIT: The entire set was dead, meaning it's not just one battery problem. It could be the lithium battery though because when I switched batteries to see which one was dead one by one I got two RAM clears. But I still don't know how the lithium battery dying could drain AAA's power within 15 minutes of use within 2 days?
-
Well when the lithium battery is dead it uses power from the AAA's to maintain the ram. If it wasn't the lithium battery your ram wouldn't have cleared when you changed the battery's.
-
well it didn't cleared all the time tho, just twice, out of 4. So this means batteries are still being eaten when calc is turned off then?
-
if the lithium battery is low then they will most likely drain when the calc is off then yes. tough just remember you calc is never really off unless there are no batteries in it, it is just in a low power state waiting for you to press on though even if you lithium battery is low it shouldn't drain that fast.
-
ah I understand what you mean now