Calculator Community > Elimination

Would you enjoy playing Elimination in its current state?

<< < (2/3) > >>

coelurus:
Sorry for not browsing through all the threads is this has been answered, but how did you implement the grayscale?

I used the following reasoning when I made Gemini:
*) I valued fluid graphics and controls above pretty much everything else. This ruled out grayscale, large screen space and other things that munch fillrate.
*) I tried to utilize as many pixels individually as possible, early pixel-doubling tests looked too blocky imho and I opted for the reduced viewport instead.
*) I wanted things to be pretty clear, which is really hard with a nearest neighbour scaler, but mipmapping was not viable on the TI83s. Instead I tried to make textures and sprites with rather large white or black areas instead of putting a lot of details in, can't remember how well I managed...

Imho, I'd trade grayscale for per-pixel fidelity and speed in any game, in this case I'd trade casting every column individually to grayscale in a heartbeat. Grayscale is wonderful for "lazy" 2D graphics (i.e. shuffling around rather than redrawing) but 3D graphics should focus on accurate transforms and there were still a bunch of glitches in Gemini at release.

Look into the table generator program, there's a rounding problem in there which produces jagged texturing that I never solved. Looking down a wall, a horizontal band in a texture should monotonically reach the center of the screen, but there's noticeable jumping in screen space. This is just arithmetics in a C program and would need no tinkering in the z80 code. And as I mentioned in another post, play around with the perspective tables a bit to make the walls a wee bit fatter.

Spyro543:
Instead of stretching the screen, why don't you just use only a part of the screen? Sure you'll have a lot of blank area, but I'll look so much better.

Hot_Dog:

--- Quote from: Spyro543 on February 01, 2012, 02:17:01 pm ---Instead of stretching the screen, why don't you just use only a part of the screen? Sure you'll have a lot of blank area, but I'll look so much better.

--- End quote ---

Because so many people complained about lack of fullscreen in Gemini.  Assuming that new fidelity will solve the blocky walls, there will be no need to stretch the screen or use only part of the screen.

EDIT: Btw, to answer your question coelurus, the Ti-83+ SE and Ti-84+ calculators have extra RAM, so I was able to create two textures for each wall, thus allowing 3-way grayscale

DJ Omnimaga:

--- Quote from: Hot_Dog on February 01, 2012, 09:15:48 pm ---
--- Quote from: Spyro543 on February 01, 2012, 02:17:01 pm ---Instead of stretching the screen, why don't you just use only a part of the screen? Sure you'll have a lot of blank area, but I'll look so much better.

--- End quote ---

Because so many people complained about lack of fullscreen in Gemini.

--- End quote ---
^This. I'm part of the TI community since before Gemini came out in June 2002, and almost everyone, even those who liked Gemini a lot, complained about the small screen size and the RAM requirement.

Question, though: Have you tried only rendering every two vertical row or something? I think that instead of having a few pixels being 2x2 large and others 1x1, 2x1 and 1x2, it would be best that the entire screen is 1x1 pixels or everything 2x1. The latter would still be a bit blocky, but it would look more uniform.

coelurus:
I tried the 15MHz switch on the TI83+SE when Gemini was finished and it was way too fast, what are the major reasons that Elimination can not go from 64 to 96 columns? Compared to Gemini's target freq at 6 MHz, 15 MHz is more than doubled up and 96/64=1.5. Grayscale+background?

I can't remember the results of my profiling tests, which is slower of the casting and the texturing?

The texture scaler was based on looping 1:1 in screen space, having the coord LUT increase texture offset and a mem read for every pixel. What about walking 1:1 in texture space + drawing piecewise vertical lines in screen space? More overhead for piece setup but fewer mem reads. Lots of things to try here actually:
For small slivers, the 1:1 screen space code is probably optimal.
For big slivers, storing textures in a vertical rle-fashion could be interesting, to piece together the vertical lines.
Sorry, getting carried away, but I still think the wall LUT generator needs to be looked over, the jumpy texture coords are probably a major reason why the graphics look a bit more blocky than they should. I think I'll have a look myself.

People complaining about the small viewport in Gemini (which they rightfully did) isn't really reason enough to double pixels. Again, on a 96x64 screen, the spatial extent of every pixel counts so treat every pixel with love and cut the fancy additions and do 96 proper casts. Doubling for 96 would use only 48 casts, but the non-uniform scaling is pretty bad. Just my opinion of course...

I think some ornamental objects are a tad too detailed, could you try and reduce the complexity a bit and rely instead on big white/black areas? Outlines don't need to be very thick then.

Navigation

[0] Message Index

[#] Next page

[*] Previous page