Re: Seriously, what is it you guys want?
We need graphics.
*CAE_Jones has entered the chat*
The most troublesome thing about the graphics for the JFIMA was finding a way to convey the 3d information without being able to do propper 3d. What I wound up going with was brightness, with the characters having outlines that vary in brightness. I'd rather have gone isometric rather than top-down, but walls would have gotten in the way. I at least made windows and doors look slightly more retro-style pseudo 3d, just by making windows semitransparent and having both extend above their tiles, but they did not extend in a way that reflects their full height.
... wait wtf did I just start rambling in the middle of a conversation nobody was having am I going senile or something I'm not that old
Ahem.
For simple, not-so-marketable 3d graphics in Python, Visual was the simplest. Trouble is, aside from it being quite old, I just couldn't get it to work. I'm not sure what I did wrong. Did I mess up the camera or something? The real annoying part was that, to check what I was doing, I basically had to write an example, take a screenshot, and upload that to Facebook and hope someone commented to tell me what happened. ... Have Not messed with this since I got decent image analyzing tools?
But for comparison, 30 lines of setup and creating complex datastructures and shaders and crap in openGL or whatever, two lines in visual. One of which is setup. The other being literally "visual.sphere(center=(x, y, z), size=r, color=red)". Get the camera in the right place, and you're done. Crap, would be nice if 2d graphics could be that convenient, even. I've tried writing a graphics_pool several times, but keep getting distracted by extra features.
But no, I don't think graphics are the solution, sadly. Not sure if I ever uploaded a version of the Jeqocon Console where the JFIMA had graphics, and I don't recall what state the graphics for the other games was on release. The biggest problem is character art. I can do crappy scenery. That's easy. For some reason, even my stick figures look terrible by stick figure standards, and I never actually manage to make anything that can use them, or finish viable code for such a thing.
Were I to add graphics to ECTAS, I'd get real confused about how to determine draw-order on bodyparts. But I would try to do a simple model system, where characters just have colors for all the big obvious stuff that I'd be drawing as thick line segments and hidious polygons / circles, then try to figure out which limb to replace with the hitArea and guardArea for attacks. Although the way grabbing works, that could get complicated ... and I think that might explain a weird shadow effect I was getting in the Braille output at one point. ... I almost hope nobody tried the Braille in that game, just because the released beta had the bad clock that caused serious jerky animation, and I treated the ground as a single line and therefore forgot to stagger water, making for some unappealing sections where water was a bunch of 'l's flowing across the screen. ... Also I couldn't get high platforms to show up correctly
On the upside, if I ever do release the stuff that's changed, the animation jerkiness should be mostly resolved, and I threw in at least one trick that makes more sense if you're viewing the inaudible Braille scenery. I had to take a bunch of stuff out, though, because it was cluttering things up to the point of unusability. Episode 1 originally had a ton of Braille vegetation, and a watermark animation for, like, leaves in the wind or something. But leaves already have a looping animation, so an additional one just confuses things. Would be nice to have, say, tar dripping from a tree, but the Braille support I put in there does not include animated scenery elements like that (the fire and waterfall animations are based on the terrain, not separate objects).
Um, I also just mentioned all of the issues I can recall ECTAS's Braille output having. I threw that together really quickly, on a holiday weekend or something. I'm simultaneously astounded that I got something that complex working that quickly, and perplexed that I only manage to pull crap like that when it's for features nobody is going to use. I mean, this is not a leisurely one-handed game, unless you have a very interesting controller (or possibly modded a braille display to replace the body of a Nintendo Switch, which ... someone please try this?).
What were we talking about?
Oh, right. Negative Nancies and weird unsatisfiable wants. I wrote a couple pessimistic replies since this thread went up, but didn't post them because they were terrible and useless. And I think this post ... actually gets the point across better, in a weird, poetic sort of way.
... O.O you got me started on graphics, and I just want to keep typing. I don't even have anything useful to add. Learn how to use 8-bit mode and palette-swapping, because transparency / alpha for shadow, water, glow, etc is actually pretty slow? In fairness, it's been like 10 years since I tried it with transparency, and computers are faster now, but overusing these, or gradients, really caused the games to lag. If it's something which can be pre-drawn and saved in a surface / BufferedImage / image file / whatever, do that. If it's simplistic 2d graphics, I'd recommend at least considering palette-swaps instead of transparencies for environmental effects (retro-style graphics call for a retro-style solution, sometimes?). And go try the tools in Magurp's signature; they help.
Lezee, how else can I drag this out, instead of sleeping? Umm, so I suppose there's no point unless you have a third party watching on a Braille display, but one thing I had trouble with in ECTAS was hitArea animation. As in, I wanted to draw hitAreas on the display, but they wouldn't show up right. But I also wonder if that's even a good idea, especially since the hit areas can overlap the attacking character, and I don't have a good solution for what to do when they overlap in Braille (visually, it's not that hard, because the hitArea is being drawn in place of the shape for the limb/weapon doing the attacking, but Braille can't support that level of detail). I don't remember projectiles showing up, either. Ooh, should characters have some kinda stun animation, too, so our hypothetical third party viewer can know for sure when an attack connects? What would that even look like, since I'm currently just cycling through the letters in their name for Brailleing characters? Maybe they should flicker, like a lot of retro games had players flicker when stunned so you'd know when they can be hit again? But I'd be worried about really fast flickering being bad for the device. Not that this seemed to bother it for the weather effects, but whatever.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
