1
Elimination / Re: Would you enjoy playing Elimination in its current state?
« on: February 02, 2012, 08:33:01 am »
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.
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.