Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Iambian on May 28, 2009, 09:48:16 pm
-
I admit it. I feel rather lazy, but I *have* tried to use Google to look for these things with little or no luck.
What are the more popular 4lv grayscale packages out there and, if possible, a link to them.
( The purpose of getting one of these packages is NOT to actually copy and paste them. I need to have a look at them to figure out how they work so I can implement a version of it myself. The grayscale used in CaDan just won't cut it for the bigger project... )
-
http://www.omnimaga.org/index.php?action=downloads;sa=view;down=234
-
That's basic if memory serves me right maxcoderz has some not quite sure though.
-
thats not basic it says so
-
All grayscale kits from Omnimaga that are located in the "Our TI/PC products" section are for Omnicalc, xLIB and Celtic III.
The best one would be Jim E revolution grayscale package, but it was on Revsoft, which is gone. The other one is from Duck, but it's slower, as it was the first gs attempt on calc and Idk if it's still on Maxcoderz, since they trashed their downloads 3 years ago. You might want to ask tr1p1ea or calc84maniac if theirs are finished. Maybe they could hand you a copy or help you. Or you could e-mail Jim E on Maxcoderz, but I am unsure if he will respond right away
-
If you want a very extensive talk on how it works then check out tr1p1ea's response on MaxCoderz.: http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692
It gives a bit of history, explains the advantages and disadvantages of some of the processes, and also gives an in-depth explanation of how interlacing achieves greyscale.
-
For "modern" ones there is RGP and GGP. Actually there one more lib. (not worth I think) And other programs that do gray...
RGP is better but it never had a complete release. But the betas are very usable and has the essential. Jim e's code is easier to follow that GPP, I think. At least I understood Jim's.
For GPP see ticalc and RGP, I have most packages jim e released in Revsoft. I can zip to you.
I did a bit use of jim e pack... tr1p1ea has its own routines and he will be releasing code for the rewritten Desolate. (basically talk to him)
And more than seeing code, could be good to see some posts in Maxcoderz... Revsoft had too. At night I can show the links.
-
is tr1p1ea even on this forum? he has some of the best games!
-
he visits MaxCoderz frequently, altough he is far less active than he used to 3 years ago
-
ive seen the name. Tr1p1ea somewhere..
-
ive seen the name. Tr1p1ea somewhere..
He sometimes visits most TI forums and leave some replies. ;)
Also he is a "successful" coder. Most well know projects are xLib and Desolate.
-
Ohhhh! Xlib. yeah. That's where I saw his username
-
i know him from Desolate and Life can be happy after all
-
Thanks for the information. The most useful thing to me was Halifax's post, which contained a link to how 4 level grayscale is achieved.
Again, Thanks!
-
ok, you're welcome, even though all i did was give you a link... can someboy write an xlib source code for 3level grayscale, 62x94, pics 1 through 3? its for a flag that is red white blue and black (white as level 0, all pics, red as level 1, pic 3, blue as level 2, pic 2 and 3, black as level 3, all pics)
-
ok, you're welcome, even though all i did was give you a link... can someboy write an xlib source code for 3level grayscale, 62x94, pics 1 through 3? its for a flag that is red white blue and black (white as level 0, all pics, red as level 1, pic 3, blue as level 2, pic 2 and 3, black as level 3, all pics)
There is a tutorial like that.
See ti-freakware.
Iambian, if you are interest I have a bunch of related links like that.
-
Well assuming you mean the guide to TI-83+SE BASIC grayscale, the issue is that this tutorial is for Omnicalc (and now Celtic III, as Celtic does Omnicalc Sprite( command) and the way it does it is pretty much slower than if we used xLIB Real(3 function. But back then xLIB APP didn't even existed at all (if you download the tutorial from Omnimaga, you will notice it even uses a 8xp version of xLIB)
-
Well assuming you mean the guide to TI-83+SE BASIC grayscale, the issue is that this tutorial is for Omnicalc (and now Celtic III, as Celtic does Omnicalc Sprite( command) and the way it does it is pretty much slower than if we used xLIB Real(3 function. But back then xLIB APP didn't even existed at all (if you download the tutorial from Omnimaga, you will notice it even uses a 8xp version of xLIB)
http://tifreakware.net/tutorials/83p/b/cdi/l3.htm
Grayscale using xLib
And it has the real( thing intercept... I think it is the app version...
-
Oh that one, I thought you meant mine from 2004. Actually despite having it in our archives, I think I will repost it directly on forums at one point
-
thanks guys! im making the american flag, which is hard to combat, seeing as the canadian flag is two colors!! muahahaha!! lol... :p i dont care, i just made it cuz it seemed cool, not to combat any canadians
EDIT: uh... this tutorial is for 255 pics, and i really am not comfortable with 255 pics, so can somebody link me a new tutorial, or just write a source? i got pic 1 2 and 3 all set up, like the tutorial said, but i dont like using their source... its a great tutorial though!
-
Information is already down, and I'm done with what I needed. From the stuff found on this site (linked to by a much earlier post) http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692
, I've built a custom 4lv grayscale routine. It actually works out *very* well, on both the emulator and the hardware.
Unfortunately, there was some kind of bug that screwed up the OS in a very subtle way. The kind of problem that I'm at the moment trying to solve via OS reinstallation.
-
i am not that good at asm to do that, as in a previous post, i said that all i could do was .db and bcalls
-
Information is already down, and I'm done with what I needed. From the stuff found on this site (linked to by a much earlier post) http://www.junemann.nl/maxcoderz/viewtopic.php?f=5&t=2692
, I've built a custom 4lv grayscale routine. It actually works out *very* well, on both the emulator and the hardware.
Unfortunately, there was some kind of bug that screwed up the OS in a very subtle way. The kind of problem that I'm at the moment trying to solve via OS reinstallation.
ouch I do hope a OS reinstall fixes it x.x
-
I didn't resist to ask. Iambian did you use interlacing in the routine?
If one day I get very high, I will try to do a 8lvl gray interlace routine :o Discovering a better rearrange of the logic to buffers to a more z80 efficient way would be fun. Figuring that out is only the easy part. :P
Also I need to understand one thing. GGP has the active buffer and the other where you plot things. (actually RGP mimics that but the libs available aren't meant to be the real release) Wouldn't just using the active buffers do the same job?
Well for this question, I should go to revsoft, maxcoderz or UnitedTI... But I am also curious to know how your routines will come out.
And I hope too that the OS reinstall works.
-
it's for double buffering, which offers advantages like artifact reduction and being "smoother" Keep in mind the active buffers MUST be together. when the app was originally written, it was realized that 768x2 and some extra bytes were needed straight out of RAM. RGP is good enough for almost anything you'd normally write. heck, with a little ingenuity, you can make a game that's looks good and has a lot of action. but for things like SSB, it's reasonable that tr1p1ea made his own (other than the fact he's a genius).
I suggest you keep the double buffering unless you really want to allocate plotsscreen and appbackupscreen for other variables.
blame the LCD controller on all calcs except 86s for not being able to do good gs. memory mapping would eliminated the port communication that makes gs such a drag.
-
Doesn't the TI-85, TI-92 and the old TI-89s and 92s also does good grayscale? I do remember some quite nice looking grayscale games on my TI-85, altough it seemed a bit slow.
the LCD on lower number models calcs is a serious issue, though. Even BASIC programmers using libraries to do grayscale has trouble keeping the grayscale from showing a checkered pattern (3 level) because the checkered pattern areas are either inverted too quickly or too slow. A long while ago I had an xLIB routine doing 3 level grayscale and it looked better on my regular TI-83+ than my TI-83+SE.
-
Doesn't the TI-85, TI-92 and the old TI-89s and 92s also does good grayscale? I do remember some quite nice looking grayscale games on my TI-85, altough it seemed a bit slow.
the LCD on lower number models calcs is a serious issue, though. Even BASIC programmers using libraries to do grayscale has trouble keeping the grayscale from showing a checkered pattern (3 level) because the checkered pattern areas are either inverted too quickly or too slow. A long while ago I had an xLIB routine doing 3 level grayscale and it looked better on my regular TI-83+ than my TI-83+SE.
BASIC doesn't help much for reducing the check effect... It is hard to update the screen enough and in the right timing.
Nor the lcd that really sucks.
-
True. You got to add basic commands to slow it down a bit or put less grayscale commands, but sometimes it's still crappy quality cuz the grayscale scanlines won't move at a constant speed
-
I didn't resist to ask. Iambian did you use interlacing in the routine?
[...]
And I hope too that the OS reinstall works.
When you say "interlacing", are you referring to the method that the information is written to the screen or the form the data takes in the buffer? If you are talking about how it's drawn on the screen, yah. That's where the "wavy" effect comes from.
The issue about the OS was resolved. Apparently, doing a "RAM Reset" doesn't do something important to the flag, which was being screwed up. Specifically, IY wasn't being set back to the correct value. In PTI, the RAM reset resolves the issue, so I'm guessing it either might be how the real calc initializes, or that the newer TI-OSes are being made crappier and crappier.
On something similar, the RAM usage reflects that of CaDan, in which the RAM is rearranged such that the strip of RAM between $8000 and $8E00 is free for scratch work. This method works incredibly well for grayscale, since I can flip a bit to refer to the other buffer (with a 256 byte gap in between since the bit flip occurs as 1024 chunks). I do plan on interleaving the data so I can go with a straight 1536 byte buffer so I can completely avoid having to switch buffers. I have the option now of going ahead to vertically align the buffer, which would make tilemapping much easier to speed up.
To avoid mentioned "artifacts", all the tilemapping updates are going to be done in the interrupt between gray drawing cycles. Sure, it *might* be a little slow, but I believe this will work out wonderfully. Since the game's text and menus occur on a grid divisible by 4, that, too, will be handled by an "aligned" 4x4 tilemapper. The timings have already been worked out for that, and I expect it to work great.
EDIT: Just realized that I forgot which thread I was posting in. Since I'm not going to move it, I'll just link to where it was supposed to go: http://ourl.ca/3383/62977