Battle for Wesnoth

[hasty basin]

Haha, I just tried playing without gptokeyb running and indeed the touch screen works perfectly. Clicks are registered. So it's definitely an interaction between having both mouse and touch.

[candid bane]

whoa, that had not occurred to me

[hasty basin]

I mean without gptokeyb there's no mouse but the touchscreen works properly. However with gptokeyb running the mouse doesn't work quite right but also the touchscreen can't seem to click buttons either

[candid bane]

so the code is assuming you have either touch or mouse, but not both? and if you have both, its assumptions break?

[hasty basin]

Correct. There's a flag in SDL where you can tell it to interpret touch events as mouse clicks, and the game sets this but only when a mouse is connected.

But also it gets confused when touch events hit in between mouse events and it sets flags to indicate a touch-drag which then disables the mouse clicks.

I'm working up a fix.

It's super byzantine though... there's like five boolean flags for mouse and touch events that all get set and cleared in different sequences and then touch events are converted partially to mouse events it's a mess

[candid bane]

could we use an environment variable to enable (a) mouse only or (b) touch only so there's never any interaction?

ok, sounds like you have a better plan

[hasty basin]

Yeah, hopefully we can make it all work. That's a good fallback approach but playing on my rg353v with only touch is a bit tedious with the small screen and my fat fingers.

My build got corrupted and I had to redo it, and building takes about 3 hours so it's slow going.

[candid bane]

ouch. if it's that slow, might be more convenient to use my github action to build -- you could redirect it to get code from your own fork of the wesnoth repo (or wherever)

[hasty basin]

naw, incremental builds are fast I just wiped my build because it started failing for some weird error in a file I'd never touched. x86 builds are fast so I can kinda test on x86 and then build for aarch64 when I think it works

[candid bane]

makes sense

[hasty basin]

strangely I'm getting gcc segfaults randomly in docker.

doesn't seem to be OOM. Re-running seems to work

while ! make -j8; do make -j8; done

[candid bane]

might be more reliable with -j2 or something

(potentially even slower obvs)

[hasty basin]

yeah it is and it is

[candid bane]

i just had a look and upstream has a discord server, erm i mean discord to IRC bridge, might be useful

[hasty basin]

Oh man, I need to be more optimistic, but I know for sure with this code quality that that is going to be a whole wasteland of apathy

[candid bane]

(yup, might only be useful for timetravelling back to the days of IRC)

[hasty basin]

remembers how to type /me

haha /me works in discord

[candid bane]

omg /nick works as well

[hasty basin]

haha It's 1996 again!

[candid bane]

hopes that discord isn't actually based on ancient IRC code

[hasty basin]

jabber

I learned erlang hacking on some erlang jabber implementation that was fucking brilliant though.... ejabberd. So much friction to do anything and then you become enlightened about functional programming and like... holy shit I will never have bugs again.

[candid bane]

never have any bugs because your brain explodes before you actually write the program

i like functional languages, in the abstract. they are cool.

[hasty basin]

Can't have off-by-one errors because your array indexes are immutable

Yeah, I've seen functional die-hards try Go and then be like, "Actually mutability is kinda convenient"

[hasty basin]

I think it's a wayland thing

Did a ton of debug prints in the game and it's getting WINDOW_LEAVE events at the timeout and the hardware cursor disappears and doesn't report the button-down events when it's clicked.

https://discourse.libsdl.org/t/sdl-wayland-handle-mouse-focus-when-receiving-touch-events-867d8/47844

RK3566:~/.config/sway # head -1 ~/.config/sway/config 
seat * hide_cursor 1000

why tho

[hasty basin]

So deleting that line fixes the cursor timeout problem. There's still the touchpad problem... and I'm not sure why that persists. Without a mouse the touchpad works fine but with a mouse it doesn't deliver clicks.

However, there's a bigger problem in that you don't want to delete that sway config line because it's for all portmaster games including ones that don't have a mouse.

you could do a thing like that but that only takes effect when sway is restarted so you'd have to kill the persistent rocknix sway and then restart it with a new config path

and then kill it again when you exit and restart the old one

Anyways, it's late here but I think you have a few tools to take this over the finish line.

[candid bane]

thanks for all your work on this! will process

[hasty basin]

The crazy thing is, why does Starbound not have any of these problems? I wonder if we can switch rendering to an open gl texture and stop using wayland.

[hasty basin]

export SDL_VIDEODRIVER="kmsdrm"
This works but for some reason the cursor isn't visible even with the simcursor. Also the touchscreen doesn't work.

But it at least delivers all mouse clicks to the game

[candid bane]

i will try to get time over the weekend to understand this better.

[hasty basin]

Do you have a rocknix device?

[candid bane]

yes

(no touchscreen)

[hasty basin]

I'll keep fiddling with it too but I'm not available this weekend.

[hasty basin]

Btw using kmsdrm also requires killing sway so probably better to stay on Wayland backend

[candid bane]

Just been trying this again on desktop ubuntu with the touchscreen emulator, and it seems to be working better than last time. Right now, if I generate a touch event, the cursor disappears immediately, and comes back immediately if I move the mouse. There's currently no problem with mouse clicks not registering after that.

So I would guess this is intended behaviour (though I don't really understand why the mouse cursor would hide at all). And my understanding is that on rocknix, if I did the same thing, the mouse would auto-hide when not used, or after a touch event, and would require an extra click to bring it back, and a second click on a UI element to register an actual click. Is that right?

(I can test on rocknix with the emulator later but not enough time now before kid ferrying duties)

OK, maybe we can split this into two problems. Problem (1): mouse doesn't work right. Problem (2): touchscreen doesn't register clicks. I think problem (1) is essential to solve and (2) is a 'nice to have'. (Also Problem (3): mouse auto-hides, but that wouldn't be a problem if (1) and (2) were OK)

And I think that 'mouse doesn't work right', more precisely, is that mouse clicks only register about half the time, and so you have to click twice to activate a UI element.

This seems to happen only on rocknix(?) and only if the device has a touchscreen. If the device has a touchscreen, then problem (1) occurs, even if touch is disabled in the game. And we don't have a way to prevent this.

[hasty basin]

Agreed. Just testing in Starbound, the mouse does indeed auto-hide but clicks are always delivered through to the game so its unnoticeable.

SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH might be a solution here but it didn't seem to help for me.

I believe this issue is independent of a touch screen but my only rocknix device has a touchscreen. The thing is, most 2gig devices run rocknix

One thing to note, when the mouse auto-hides, the windowing system sends SDL_WINDOWLEAVE events to the game implying that its window is no longer in focus. Wesnoth seems to handle those events but changing the code to ignore them didn't help either.

[hasty basin]

Ok, change of plans. I have another day to work on this.

[hasty basin]

swaymsg might be a solution to turn off the timeout, but I'm still grinding through the actual wesnoth code to see why it's being dumb about mouse down/up events. There's a lot of moving parts.

[hasty basin]

swaymsg 'seat * hide_cursor 0'

Above command fixes the problem. We can add it to the launch script. I'm researching how to query that value so we can potentially put it back, but a janky way is to just grep it out of the sway config and barf it back into swaymsg.
I'm gonna poke around to figure out why touchscreen doesn't work though when a mouse is present.

RK3566:/roms/ports/wesnoth # swaymsg -t get_config -p | grep hide_cursor
seat * hide_cursor 1000

even if we change it, this will reliably echo the previous value

which we can pass back into swaymsg:

swaymsg "$(swaymsg -t get_config -p | grep hide_cursor)"

[daring igloo]

Good collab 🙂

[hasty basin]

only because ben has childcare duties and I have the whole day free. I feel like I brute force everything and he hits the right answer immediately.

[daring igloo]

same lol

he fixed all the ones where i hit a wall 😄

[hasty basin]

I'm really surprised we haven't seen this before, and I have no idea why it's not present on Starobund

I think wesnoth is too fancy with it's window handling code. Holy shit it's a mess to read though with multiple #ifdefs for different platforms and state booleans of every combination.

[candid bane]

no way man -- i am struggling to understand the problem and it sounds like you have already fixed it

[hasty basin]

#1 is fixed. #2 still exists but is less important. Still, running the game without a mouse and just using touch is pretty nice. It's very conducive to touch so it'd be nice to have it all work.

[candid bane]

great work! agree re #2 but this is great progress. i am stuck this (uk) evening but will try and be useful tomorrow

[hasty basin]

Just as a summary where we're at, so you don't have to scroll up to other stuff...

By default, SDL on rocknix uses wayland with the sway compositor. On Rocknix, sway is persistent and it's configured by default to time the mouse pointer out on idle. This makes kinda sense since you don't want a hardware mouse hovering in space if your game doesn't use one.

swaymsg is a command to query and set settings for a running sway compositor, so we can use it to disable and reenable the mouse timeout:

## disable cursor auto-hide if on rocknix
if [[ ${CFW_NAME} == ROCKNIX ]]; then
  swaymsg 'seat * hide_cursor 0'
fi

USER=$HOSTNAME ./$BINARY \
  -d \
  --usercache-dir "$USERCACHE_DIR" \
  --userconfig-dir "$USERCONFIG_DIR" \
  --userdata-dir "$USERDATA_DIR" \
  ./gamedata

## put cursor auto-hide back on rocknix
if [[ ${CFW_NAME} == ROCKNIX ]]; then
  swaymsg "$(swaymsg -t get_config -p | grep hide_cursor)"
fi
  
pm_finish

[lofty tundra]

That certainly is another way

[hasty basin]

Dude, this took me multiple days to figure out...

gigantic yak shave

[lofty tundra]

Same. Don't feel bad 😛

[hasty basin]

haha... I feel your pain

Have you ever figured out how to fix the touch screen not working when a mouse is present?

[lofty tundra]

The devs are aware of it, too. Although, I'm not sure what the status is of them making any changes to sway in their CFW.

[lofty tundra]

Negative.

To be totally honest, I don't ever use the touch screens on mine.

[hasty basin]

k... I'm in the middle of yak shave #2 to fix that

Well, this game is very gui dependent and only runs on 2 gigs which often has touch screens so I think it would be useful to suport

[lofty tundra]

I agree. I regret to inform that I'm not well versed with how the touch screens are implemented unfortunately.

Not that I couldn't figure it out, but I haven't ventured into it.

[hasty basin]

that makes two of us. Hell I didn't know what sway was when I started this bug fix

[lofty tundra]

Hahaha same

[hasty basin]

I'm glad we're not insane, we kept saying, "Why hasn't anyone seen this before?"

[lofty tundra]

Lol. Hopefully I helped by at least pointing out that I've seen it before when fixing OpenTTD more than a few months back, but having said that...

It took me quite some time to track down that it was sway. Shoot! Had you messaged me earlier I could have spared you the headache at least figuring out the sway part.

[hasty basin]

heh, we asked a few times but I know how busy discord is

[lofty tundra]

True. I'm not as active as I once was, but I always promise that I'm not gone. If someone pings me - I'm sure to respond.

I'll never be truely gone.

I love PM too much.

Heck. If I get some massive free time again at some point, I'll start testing a bunch of stuff again like I once was.

[hasty basin]

eh, this is my leisure activity. As long as it's fun and I have time, I keep doing it, but you should never feel obligated to do your leisure activity. The fact that you've volunteered so many of your hours already is admirable.

[lofty tundra]

I appreciate that. On that note, most everything I've done here is because I really enjoy it and the sense of accomplishment in doing this stuff cannot be overstated.

[hasty basin]

https://github.com/libsdl-org/SDL/commit/21879faf4815a6acdb29e290d51a15bbe4dae03e

This probably isn't fixable outside of SDL/Wayland/sway without generating a ton of fake events and then grabbing the window control back. meh.

[hasty basin]

I think I'll just declare victory on the mouse working and abandon attempts to get both mouse and touch working.

[lofty tundra]

Hmmm... I am aware of how when the touch screen detects input that the mouse is disabled during the use of the touch screen. That's been the defacto for some time. Now, whether using the touch screen permanently disables mouse or visa-versa I'd like to assume that it should be able to dynamically switch between them on-the-fly without issue. I guess by what you're telling me is that there's some issue with using the touch screen and one method of input disrupts the other input device? I am also aware that at one point some CFWs had very limited touch screen support and even if ROCKNIX has decent support, it wouldn't be the first time I've seen weird behavior on ROCKNIX.

By the sound of it, just the mouse being present even if it isn't being used is causing the touch screen to not work. It's really supposed to allow touch input so long as the mouse isn't receiving movement input, but I guess that's not the case here. I'm not sure right off how to work around that.

[hasty basin]

Yeah, what happens is that when you tap the screen, sway hides the cursor and sends a LEAVE event to the running application basically telling it that the mouse is no longer there. SDL however assumes that LEAVE events are only when the mouse moves off the active window and so it stops listening to mouse events. This is a bug in SDL, and the above patch fixes it but not in the version we're using. This is all complicated because wesnoth has a pretty robust windowing system inside it so it responds to the leave events as well. It would be possible to intercept these events and fabricate fake ones to make sure everything works as intended, but bleh, it's not easy given wesnoth's complexity.

The correct solution is to just get a version of SDL that has the above patch.

But yeah, if you don't have a mouse pointer, then sway doesn't tell the application that the mouse is LEAVEing so everything touch works fine.

[lofty tundra]

Oof

I'm with you. If the mouse is working, I'd call it a day.

[hasty basin]

Strangely in my port of Starbound on the same system, touch events work just fine, but I think starbound's input handling is much dumber so it doesn't get confused

[lofty tundra]

Quite possible. On that note you could address it by re-writing the input handling of the game in question, but that might still be more work than what it's worth.

[hasty basin]

I'm pretty deep in to changing the wesnoth input event handling today but it's gnar

[lofty tundra]

I gotcha

[hasty basin]

big walls of C++ are normally my jam but this thing is woah.

It's a 20 year old multiple contributor project and the code looks like that

[lofty tundra]

Geez

[hasty basin]

https://github.com/wesnoth/wesnoth/blob/b3beb3eab73c8b42710743e21e19e136490f9005/src/gui/core/event/distributor.cpp#L446

[lofty tundra]

I see several places in there that are responsible for handling the input focus. I'd have to stare at it for a few to think what could be done to improve it.

[hasty basin]

Depending on context, clicking the mouse will generate one or many of these events:

LEFT_BUTTON_DOWN
LEFT_BUTTON_UP
LEFT_BUTTON_CLICK
SDL_LEFT_BUTTON_DOWN
SDL_LEFT_BUTTON_UP
SDL_TOUCH_DOWN
SDL_TOUCH_UP

[twin quiver]

This might help one of my old ports

As in the hide cursor

[lofty tundra]

You're referring to how sway hides it after only 1 sec?

[hasty basin]

and then SDL thinks "hide" means "start ignoring the mouse completely"

[lofty tundra]

Sometimes it does that

[twin quiver]

Or is there a way to completely disable it?

GunGodz has the issue with the mouse on Rocknix

[hasty basin]

## disable cursor auto-hide if on rocknix
if [[ ${CFW_NAME} == ROCKNIX ]]; then
  swaymsg 'seat * hide_cursor 0'
fi

[lofty tundra]

GunGodz has a different issue.

[hasty basin]

This disables the auto hide. But you want the auto-hide for non mouse games or you'll have a mouse cursor on screen for the whole game.

## put cursor auto-hide back on rocknix
if [[ ${CFW_NAME} == ROCKNIX ]]; then
  swaymsg "$(swaymsg -t get_config -p | grep hide_cursor)"
fi

[lofty tundra]

That's where I just add SDL_ShowCursor(DISABLE) to the code somewhere.

[hasty basin]

so this puts it back when your port is done

[hasty basin]

yeah, but for like other emulators or other system applications.

[lofty tundra]

True

[twin quiver]

Shall try to add that in when I have the time

[lofty tundra]

What bmdhacks has is pretty good. When I did it for OpenTTD I just set the mouse hide timer for like 10+ minutes where it'd be highly unlikely that someone playing would stare at the screen long enough for it to disappear lol.

Anywho, I'll be back after a bit. Gotta run out and help a guy with his computers. I'll see how things are moving along with y'all when I get back.

[twin quiver]

And yes I realise GunGodz issue is the opposite

[eternal briar]

Just chiming in to say that a lot of us without touch screens are probably very much in favor of you declaring your partial victory and moving on :).

[hasty basin]

Well its still 2gig only so there aren't a ton of 2gig non touchscreens out there. Powkiddy x55... What else?

[eternal briar]

ack forgive me for reading quickly, I hadn't noticed the 2gb requirement!

[candid bane]

This is fantastic. Great work bmdhacks! If I’m reading you correctly, it might be possible to make a version of hacksdl that implements this patch

I will have a go today

[candid bane]

On knulli, I think zswap gives you enough memory to run it. It’s worth trying. I am still hopeful that we might reduce ram usage enough that this isn’t required

[candid bane]

(doesn't look possible due to the relevant functions being internal to SDL)

[candid bane]

.sh fix seems 100% effective in making the mouse work reliably

[candid bane]

one option might be to make this rocknix-only? given that rocknix has 512MB swap by default, which seem enough. better than making it require 2GB

[hasty basin]

Have you looked at a massif or heaptrack output?

Might be some low hanging fruit to get it under the limit

2 gigs for a turn based game that can load stuff on demand seems insane to me but i haven't investigated.

Seems like sprinkling around a bunch of mmap would save some space. I'm busy this weekend but i can take a look at it later maybe.

[candid bane]

never heard of before but will try. agree the memory usage seems disproproportionate

[hasty basin]

I think valgrind/massif ships with rocknix

Heaptrack is way better. I run it on my desktop linux box since profiling slows the game down a lot.

Theres also some crazy perl script you can get to generate massif flame graphs but its a bit cumbersome.

That looks like a memory leak to me

But it might just be leaked on quit... lemme check what's leaked if I detach before quit

[hasty basin]

So above I ran the intro campaign and then got into the second intro mission. Way bigger impact on memory usage. More than I'd expect. Leaked memory was constant so I don't think it's a memory leak anymore.

Virtually all the memory is consumed by display::get_terrain_images

If you wanna play around with that...

https://github.com/KDE/heaptrack

[candid bane]

perfect -- i can't get heaptrack to run without crashing the game yet, so will just try analysing yours.

[hasty basin]

The terrain images are in data/core/images/terrain

[candid bane]

get_terrain_images is not too complicated

that data dir is only 50MB

[hasty basin]

yeah and they're stored uncompressed

[candid bane]

is it caching the same image many times?

[hasty basin]

possibly. There is gonna be a doubling because it has lit/unlit/highlighted

but still... we only use a small subset of terrain types for that mission

above heaptrack is me jumping into game, loading a save of the second mission, scrolling around the entire map, clicking on every unit to highlight movement, then quickly exiting

500m memory usage

Oh, also there's TOD (time-of-day) lighting effects so when it shifts to night they cache whole new terrain tiles with all the lightmaps applied

I'm just gonna try disabling all the caches for lit/highlighted/TOD images and see how slow it goes. IE: only cache the textures off disk but any other transforms will be done on-demand

Could be that 20 years ago this was all necessary to cache but our CPUs are fast enough now

Game was originally released in 2003 and has had 500 contributors. Wikipedia says they issued a statement that they lack contributors to fix bugs but they're working on improving the game's structure.

[candid bane]

seems like there is scope for simplifying the light transitions or reducing the number of different ToDs

[hasty basin]

Perhaps, or just being more aggressive with flushing caches. you only have one TOD at a time

[candid bane]

oh, good point

[hasty basin]

display::update_tod does seem to flush the caches though

void set_color_adjustment(int r, int g, int b)
{
    if(r != red_adjust || g != green_adjust || b != blue_adjust) {
        red_adjust = r;
        green_adjust = g;
        blue_adjust = b;
        surfaces_[TOD_COLORED].flush();
        lit_surfaces_.flush();
        lit_textures_.flush();
        texture_tod_colored_.clear();
    }
}

Oh wait... this is the background tile image, but then it applies a mask via mask_surface. The TOD modified tile with mask applied is stored in a cache that is not flushed.

This is why mask_surface seemed so high in memory usage

look at get_hexed in picture.cpp

[candid bane]

wondering if we can save memory by changing texture quality from linear to nearest

[hasty basin]

Woah... disabling all the caches had a substantial improvement to memory usage

[candid bane]

performance?

[hasty basin]

seemed fine on my core i7

[candid bane]

heh

[hasty basin]

Graphs are not proportional but you can probably make out the axis scales

[candid bane]

so, 150MB with no caching, 450MB with caching

how did you disable caching exactly?

[hasty basin]

Here's a diff you can try

[candid bane]

you read my mind

[hasty basin]

I asked Claude to disable caching and then I yelled at him a few times when he made stupid mistakes.

We went back-and-forth about all the namespace bullshit but he insisted it was needed. I think it's messy but we can clean that up later.

Yeah, I don't know why he made UNSCALED into image::UNSCALED

Ok, I really gotta run now, I got caught up but have other life things to do.

I fucking love software optimization though

[candid bane]

ok i will build it and let you know how it works on device

[hasty basin]

If its too slow we can look into adding a worker thread pool for doing lighting and masking transforms.

Or also we can probably get the AI to roll some hand-tooled NEON assembly for lighting transforms

Compared to a 2003 CPU though, the rk3326 is a fucking beast

Typical 2003 Laptop Specifications

Processor:

    Likely a Pentium M (or in some cases a Pentium 4 Mobile) running roughly between 1.6 GHz and 1.8 GHz.

Memory:

    Generally equipped with 256–512 MB of DDR SDRAM (often upgradable to 1 GB in some models).

Storage:

    A hard drive in the range of 40–80 GB (5400 RPM), which was standard before the widespread adoption of larger, faster drives.

Display:

    Screen sizes were typically 14″ to 15″ with resolutions around 1024×768 pixels.

[hasty basin]

I did a bit more profiling and this takes up half a thread on my core i7. All the graphics rendering is single-threaded in the game and really there's no heavy threading used to speed it up.

Also, I believe that the SDL surface will keep the rendered image in memory so it's redundant to cache textures anyways. The only slowdown might occur at night or something when the water animations have to be recalculated each frame.

[hasty basin]

Ok just a quick test then I have to go

[candid bane]

I seem to have consistently 55MB free (out of 1GB) which is great. Scrolling is slow, hard to be sure how that compares to swapping before. Looks promising to me

[hasty basin]

Seems acceptible to me on rk3566

Note that initial scrolling will be loading tiles off disk, and then the second time you pan over it it will be generating the images

CPU is maxed with TOD modifications when hovering over water animations. but it's single-threaded here so we could speed that up if we needed

380MB resident for me

[candid bane]

yup, seems very close if not there already. nice work!

[hasty basin]

Thanks. I'd be interested in hearing some r36s feedback.

[daring igloo]

There are 2 gb devices on non rocknix 😛

rg552 has 4gb on amberelec 😛

[hasty basin]

Good to know. I think after that last patch we can get under 1gig no problem anyways, if we're not there already

[daring igloo]

❤️

[hasty basin]

All y'all linker wizards constantly impress me running roller coaster tycoon by using patchsdl and some old Amiga library. But ive got the source code. I can do whatever I want.

[hasty basin]

Ok, on trimui smart pro the no-caching patched wesnoth was like 300mb resident. My system only had 600mb out of 1 gig used. This is at full res, but it was super slow. So I think we can fiddle with caching strategies and cpu speedups to make the game both low memory and usable.

Despite the game being slow, only 1 out of 4 cores was ever used.

I would say the speed was approaching unusably slow though, so there's still work to do.

Things we can improve:

• More strategic caching of map tiles. Perhaps cache the masked/TOD-modified/etc tile and dump the rest instead of caching the one off disk and applying the lighting/mask/etc
• Multithreaded lighting. Have a worker pool handle adjust_surface_color(). This function already locks the surface with a mutex so it's a good candidate to feed to a thread.
• NEON optimization for adjust_surface_color(). It's just bulk adding r,g,b constants to a giant array which should really speed up with some neon optimizations.

Oh shit... adjust_surface_color() clones the entire image and returns a copy of the image with the coloring.... but it's used to modify a lot of stuff in-place:

                        if (need_fogging) {
                            surf = adjust_surface_color(surf, -50, -50, -50);
                            fog_cache->emplace(terrain, surf);
                        }

                        if (need_highlighting) {
                            surf = adjust_surface_color(surf, 50, 50, 50);
                            highlight_cache->emplace(terrain, surf);
                        }

We could give it a bool field to do in-place editing and that would save a ton of memory fragmentation and churn and speed it up a lot. That plus NEON and it'd be much more performant.

[hasty basin]

https://tenor.com/view/neon-city-asm-altered-state-machine-aifa-neon-sign-gif-24677759

[hasty basin]

In-place editing is probably a bad idea... hard to tell when that would work. I'd need to test that out a bit more.

[hasty basin]

I'm still fiddling with caching policy. I did the neon implementation of adjust_surface_color but it didn't speed up much on trimui.
Knulli on TSP is the worst. You only get about 400 megs of working RAM before it OOM's you.

Trimui Smart Pro is the perfect stress test though, running at 1280x720 with such a wimpy processor.

[candid bane]

have had a busy couple of days. i wondered about converting the textures to 16 or even 8 bit, or downsampling them by 50%.

[daring igloo]

Did you guys brainstorm ideas with the wesnoth people?

[hasty basin]

No but my bet is the wesnoth dev community is a wasteland. I'm still traumatized by the OpenStarbound junk show.

I've got a free day tomorrow and my head is swimming with optimizations to try. I'm feeling pretty optimistic I can work some magic.

[hasty basin]

I thought about LZ4 compression too, but i just think its premature to do that when each hex tile is cached:

a) off disk unscaled
b) with alpha mask applied.
c) with time-of-day shading applied
d) with highlight shading applied
e) as part of the SDL render surface when its blitted into the drawable.

Theres only 51 megs of uncompressed terrain tiles in the game, it seems silly to have to compromise their quality when the game is eating 500megs to render them onto the map.

[candid bane]

animate_map=no
animate_water=no
idle_anim=no
unit_standing_animations=no

these are helpful

[hasty basin]

Oh yeah animations are brutal on CPU good find

[candid bane]

they also seem to consume RAM:

Launch game, choose Brothers campaign, click through dialogue, scroll around whole map

* with cacheing and animations       RES 735
* with cacheing and no animations    RES 385
* with no cacheing and no animations RES 317

(res is from top)

Both of the no animation versions seem acceptable on my fake r36s whose CPU is weak (worse than 3326, I forget the spec).

[hasty basin]

Hell yeah! You solved it the elegant way!

[rocky river]

Yall are working so hard
hard on this! It's so awesome!!!

[hasty basin]

Hah thanks. A lot of work to find one config option for the game, and one display command.

[rocky river]

I could use some testing of amberelec and arkos on my port if either you or @candid bane have those.

[hasty basin]

Sorry I gave my r36s with arkos to my brother in law as a gift.

[rocky river]

Oh good on ya

[candid bane]

This thread is for Battle for Wesnoth. Also please do not ping me unless necessary, and particularly not with task requests.

[mortal quest]

⚠ Warned not.your.average.paladin

[rocky river]

I've been told

No more pinging. Ever. People get really mad about it I've found

[hasty basin]

This is the part where I admit I just like hacking on stuff. I've got a bit of time to test disabling animations, but i might just fiddle with caches for fun.

[candid bane]

Updated zip. This is just with the animations turned off. It seems fine to me but keen to hear how it works for others. I updated the controls a bit also:

| Button              | Action                                          |
| :------------------ | :---------------------------------------------- |
| D-pad               | Scroll                                          |
| Left analog         | Move mouse                                      |
| A                   | Select unit, move unit               Left mouse |
| B                   | Context menu, cancel action         Right mouse |
| X                   | Show enemy moves                         Ctrl-v |
| Y                   | Slow mouse                                      |
| Start               | End player's turn                    Ctrl+Space |
| Select              | Exit / cancel                               Esc |
| L1                  | Zoom in                                       - |
| L2                  | Zoom out                                      + |
| L3                  | Reset zoom                                    0 |
| R1                  | Cycle through units with moves remaining      n |
| R2                  | Toggle accelerated game mode             Ctrl-a |
| Right analog left   | Recruit unit                             Ctrl-r |
| Right analog right  | Repeat last recruit                  Ctrl-Alt-r |
| Right analog up     | Recall unit                               Alt-r |
| Right analog down   | Rename unit                              Ctrl-n |
| R3                  | Describe current unit                         d |

If you have no analog sticks, the D-pad will control the mouse.

https://drive.google.com/file/d/1vo63b7KZQfhOzqLBW6CbIZpg6uJD_R_C/view?usp=sharing

[keen garden]

✅ muOS RG35XXSP

[hasty basin]

if [[ ${CFW_NAME} == ROCKNIX ]]; then
  # sim-cursor not needed on rocknix
  cp vanilla/wesnoth .

  # disable cursor auto-hide if on rocknix
  swaymsg 'seat * hide_cursor 0'

else
  # sim-cursor usually needed on other platforms
  cp sim-cursor/wesnoth .
fi

Perhaps this would be better as a symlink instead of copying the file every launch.

[candid bane]

can't have symlinks because they're not supported by windows filesystems. i agree it doesn't feel right though...

[hasty basin]

perhaps md5sum the binary and only copy if it differs?

✅ Trimui Smart Pro - knulli. Totally playable. Dpad scrolling is smooth as butter

so psyched. this is awesome.

It's amazing that turning off animations saved so much RAM but I guess that makes sense because of the multiple frames per tile

It doesn't detract from the gameplay at all.

[candid bane]

i think this should work?

works on rocknix

[hasty basin]

Yep that works. So I'm fiddling with animations and it seems just disabling water animations (leaving the rest of them enabled) gives nearly the same memory savings.

[candid bane]

Do you think we should add the others back in? I'm inclined to think that dropping the animations probably improves performance as well, and they won't really be missed

[hasty basin]

Eh... the a133 in the Smart Pro at 1280x720 is gonna be the most underpowered you can get, and its performance seems fine. As long as the sprites are cached, blitting new animations shouldn't be that expensive, it's just a memory thing with the terribly 5x caching it does, but animated units and the few animated tiles that aren't water (village flags, windmills) just don't seem to be numerous enough to have an impact.

I'm neutral on it. If you wanna play it safe and keep them off that works for me. But from my tests it doesn't seem to have either a performance, memory, or huge visual impact to turn them on.

[rocky river]

So who's port is this now? Lol

[eternal briar]

Just tested this on my RG Cube XX running Knulli, didn't get very far but ran a few steps of the tutorial and it's running perfectly in 720x720 native 👍

[candid bane]

I’ll try it on the fake r36s which is pretty weak (rk3128). Unfortunately I broke the ArkOS install by messing with apt so I’ll have to fix that first.

[bright pendant]

are you sure its 3128? Because that would not run 64bit app 🙂

its probably 3326T, underclocked 3326

[candid bane]

It’s a collaboration. The best kind imho.

Good to know. I was going by a fake r36s website which is clearly wrong https://handhelds.miraheze.org/wiki/R36S_Clones . Would be interested to know definitively.

[hasty basin]

What does cat /proc/cpuinfo say?

[candid bane]

Good question. Will check in the morning

[rocky river]

https://handhelds.miraheze.org/wiki/R36S_Buying_Guide

[hasty basin]

For RK3128, /proc/cpuinfo will have:
CPU Part: 0xd05
For RK3326T it would be:
CPU Part: 0xd04

[eternal briar]

One minor addition I forgot to include, for me the zip didn't work in the autoinstall folder, I had to manually copy over the .sh and folder to the ports folder and then mark things as executable, and then again after the patcher did it's work I had to again mark a new thing executable (wesnoth with no file extension).

that was no biggie but I assume you folks might want to know for future automation

[hasty basin]

Good to know! I installed with harbourmaster install wesnoth.zip and it worked fine

[candid bane]

0xd04

[candid bane]

OK -- I have uploaded a new zip (animations re-enabled except water, .sh updated) to the same google drive link -- https://drive.google.com/file/d/1vo63b7KZQfhOzqLBW6CbIZpg6uJD_R_C/view?usp=sharing . I think we just need a test on amberelec:

[] AmberELEC
[X] ArkOS
[X] ROCKNIX
[X] MuOS
[X] Knulli (Optional)
[] Crossmix (Optional)

Rocknix drivers:
[X] Libmali
[X] Panfrost

Resolutions: 
[!] 480x320 (Optional)
[X] 640x480
[X] 720x720 (RGB30) (Optional)
[X] Higher resolutions (e.g., 1280x720)

<@&1216123318122577972>

[hushed cave]

How do I got about testing on MuOS? I have time this afternoon.

[candid bane]

put the zip above in the portmaster autoinstall folder (something like /mnt/mmc/MUOS/PortMaster/autoinstall), then launch PM.

[bright pendant]

/userdata/roms/ports/Battle for Wesnoth.sh: line 80: /userdata/roms/ports/wesnoth/sim-cursor/wesnoth: Permission denied
I had to chmod the simcursor binary to get it working on knulli / rgcubexx

[candid bane]

this is weird, although i guess the PM autoinstaller would fix this anyway? on my computer, the binaries are set like this:

 $ ls -lad */wesnoth
-rwxr-xr-x  1 ben  staff    28M  1 Apr 09:24 sim-cursor/wesnoth
-rwxr-xr-x  1 ben  staff    28M  1 Apr 09:24 vanilla/wesnoth
``` which looks right to me

(even after unzipping)

[bright pendant]

oh so thats a wrong on my end, I have manually unzipped

let me retry just in case.

[candid bane]

but even then, i'm surprised that your unzip is different from my unzip

[bright pendant]

do you have a regular knulli firefly or some closed build?

[candid bane]

i haven't checked the zip on knulli

[bright pendant]

ooh ok. I will do a proper install and let you know

[daring igloo]

works great 351v amberelec

[bright pendant]

yep, also on my end

[candid bane]

PR TIME 🎉

[bright pendant]

by that I meant amber, knulli is still repatching 😄 but even then it would be one extra line

[candid bane]

ok i will be patient

[bright pendant]

yep, that was it, it is fine now, pr away

[candid bane]

https://github.com/PortsMaster/PortMaster-New/pull/1460/commits/18459a1022d3fc4787cbf6b4b4cd2ebcfe2f4a40#diff-30fcb394e456be7c2795622da949cc6e54fbbbd569ef33f74d517fc2fdc001ad Thanks for everyone's contributions to this, especially bmdhacks! Feels like it has been quite a saga, but I have enjoyed figuring it out together.

[hasty basin]

So awesome this is RTR with the segmented zips. Your build environment is so good I'm gonna copy it for all my future ports.

[candid bane]

segmented zips are a PM thing not a me thing. if you find ways of making the build stuff work better on windows, let me know

[hasty basin]

I went back to where it all started, desktop linux. The irony is that the flasher for gamma os is the one thing i want a windows computer for.

[pseudo holly]

After adding a large number of missing libs, I was finally able to play Battle for Wesnoth on TSP using crossmix. The game runs very smoothly, and the resolution of 1280*720 is quite suitable for this type of game. Thanks.

[candid bane]

It would be worth documenting the missing libs here. I don't think we will add them to the port (since crossmix is not really supported in PM) but it would be useful for people who come here later. Also it may be worth letting the crossmix people know which libs you had to add -- I don't know why they are missing from crossmix, but perhaps they can be added there.

[rocky river]

CONGRATULATIONS DUUUDE!!!

[candid bane]

Can anyone test whether the interactive text input works for them? My experience: works fine on knulli, muos. Doesn't work on ArkOS/RGB20pro.

[bright pendant]

doesnt seem to work on amberelec

[daring igloo]

how did you export it?

[candid bane]

it's using gptk2, and i just have

export TEXTINPUTINTERACTIVE="Y"
$GPTOKEYB2 "$BINARY" -c "$BINARY.ini.$ANALOG_STICKS" >/dev/null &

the original reason for using gptk2 was a bug in gptk1, which is now fixed. so i'll try going back

[daring igloo]

so bug in gptokeyb2 then 😛

maybe was never implemented yet 😛

@storm skiff 😛

[bright pendant]

I have in my head that interactive mode wasnt even working at all with gptk2 not that long ago

so I guess its a bit of wip?

[daring igloo]

defo not 100% complete

[candid bane]

ok, will revert to gptk1 later and see how it goes

[hasty basin]

I use interactive in gptokeyb2 in Starbound but you dont use the env vars its a binding. Look at Starbound gptk.ini in the multiverse repo

[candid bane]

i see, will give that a go

[storm skiff]

I’m pretty certain the envvar only “works” if you do not use a gptk2.ini file, only “works” if you provide a gptk file.

[ebon zealot]

interactive input works in gptk2 in my another port , so it is definitely implemented

but you need set keys for next char, prev char and input word

#☕｜lounge message

like here

[candid bane]

ok -- fixed in this https://drive.google.com/file/d/1vo63b7KZQfhOzqLBW6CbIZpg6uJD_R_C/view?usp=share_link

[hasty basin]

Does start as 'End Turn' still work?

[candid bane]

yes -- it means when you use the hotkey you get some extra spaces in the text box, which then get deleted. i think it's the best option given that we are out of buttons

[rocky river]

Of course... lol

[hasty basin]

Just finished the two intro missions on my TSP. The ui is slightly clunky but its still really fun!

[ebon zealot]

I see you spent a lot of time improving something. is it worth updating from old test release?

[candid bane]

i would wait a few days until the final version appears on PM. but yes, it's worth updating because the old version will eventually run out of memory on 1GB devices

[ebon zealot]

so you improved ram consumption

[candid bane]

yes

[ebon zealot]

but I paid for 2 GB... i feel bad for not using them after update

😄

[hasty basin]

This really looks good

[hasty basin]

Got the game to OOM but it may have been a leak because I just loaded up the last autosave and it played fine for another hour

The RNG is brutal on this game though. I see there's some RNG prefs, I need to look at those. It'd be nicer if the RNG isn't so harsh.

[hasty basin]

Head's up... pick "Biased RNG" in the campaign selector to have a less infuriating time.

[hasty basin]

Really enjoying this port on trimui

[naive moat]

Hi, I had this error too, so I've added /usr/lib to LD_LIBRARY_PATH but now I have :

symbol lookup error: /mnt/SDCARD/Data/ports/wesnoth/libs.aarch64/libpng16.so.16: undefined symbol: inflateValidate, version ZLIB_1.2.9

Do you know how I can fix it ?

[hasty basin]

What cfw? Is this crossmix?

Use knulli. Crossmix is lacking too many important libraries to run this port.

[naive moat]

Oh OK I was thinking that you were running it from CrossMix

[hasty basin]

No we gave up when it cascaded into a massive chain of text rendering libs that dont exist in crossmix

[naive moat]

Mhhh I understand ... maybe I'll try to find the right libraries, just in case , with a little perseverance 😄

[hasty basin]

Go for it. Its basically gonna be compiling your own distro or a huge chunk of one

[pseudo holly]

After adding many libs, I ran it on crossmix. Perhaps these libs can be added to the system.

[naive moat]

(may be just take the missing libs from knulli ?)

[naive moat]

oh cool, can you share a list or the files itself ?

[hasty basin]

Knulli uses different versions of libc etc AFAIK

[naive moat]

Oh damn... I could create a kind of chroot based on knulli for CrossMix 🤔... But not sure that it will work with libc upgrade...

[hasty basin]

If youre super motivated you could go work with the crossmix team to pull it off. pango is the biggest lib in the chain that blocks most ports.

[pseudo holly]

After adding the libs, the libs.aarch64 folder reached 192M. I'm not sure how to share it on Discord.

[naive moat]

If I understand well, libpango-1.0.so.0 is required in westnoth and windstarry seems to be able to run it, so I could ask to CrossMix dev to add the missing libs for pango 👍🏻

[naive moat]

can you upload a zip to wetransfert or just send me the list of your libs in libs.aarch64 folder ?

[hasty basin]

Yep. Its a fairly large undertaking to bundle a complete library set for font internationalization but you could ask. This blocks a ton of ports on crossmix

Pango is just one of a large set of interconnected libraries that render internationalized text

But it's the primary one

[naive moat]

Thanks for the information, I will see if I can improve the situation for pango / CrossMix

[pseudo holly]

https://drive.google.com/file/d/18RWqSArN54U_PIH2cKKppaJvodOM75rz/view?usp=sharing

By file date, you can tell which libs were added.

[naive moat]

Thank you, it's very friendly !

For my curiosity, how did you identify the missing one for example when you have something like
libpng16.so.16: undefined symbol: inflateValidate, version ZLIB_1.2.9

it's already working Now I'm going to see if I can package this for crossmix, at least it will benefits to everyone 🙂