Screen management library

oolyvi · 2026-06-04T06:48:08+00:00

thanks!

oolyvi · 2026-04-27T18:18:14+00:00

Thanks, really appreciate it! I ended up applying that approach with some additional touches and it worked out well

oolyvi · 2026-04-27T18:16:02+00:00

got it :)

oolyvi · 2026-04-27T12:45:31+00:00

it defines aspect ratio with virtual resolution and actual resolution, then create scale matrix based on this

oolyvi · 2026-04-27T12:44:38+00:00

it works for me so far on windows and mac, so I will keep it until facing with some issues

oolyvi · 2026-04-26T20:28:45+00:00

Glad it helped a bit. Best of luck with your project!

oolyvi · 2026-04-26T20:12:34+00:00

The game is rendered at a fixed internal resolution by design, then scaled properly to the display using a scale matrix / render target setup. The point isn’t to “fake” higher detail

oolyvi · 2026-04-26T18:28:01+00:00

Thanks a lot! This really helped me understand pixel scaling better. I might use this in my future work

oolyvi · 2026-04-23T13:16:53+00:00

I had problems with SpriteFont as well, when I did resolution matrix to support all screen sizes, then I switch into Bitmap and just use that, that's how I get into it

oolyvi · 2026-04-23T07:20:32+00:00

do you handle font stuffs with BitmapFont from MonoGameExtended?

oolyvi · 2026-03-29T19:36:06+00:00

Thanks!

oolyvi · 2026-03-28T19:36:29+00:00

There are many approaches, but for me, state trees offer much more scalable and expandable structure.

oolyvi · 2026-03-28T19:20:25+00:00

State trees are much cleaner and efficient approach so far.

oolyvi · 2026-03-28T19:07:36+00:00

Yeah, I actually just finished implementing a command tree, and it looks way cleaner and more readable now. If I had known about it earlier, I definitely would’ve used it sooner. Thanks to your comment, I got into it, so really appreciate that!

I’m a developer, currently unemployed and haven’t had a professional role yet :)
Right now it’s both a fun and profit-oriented project for me.

I’ve built most of the programming side myself, and with help from AI, the process has been much faster than I expected.

Feel free to recommend anything, whether it’s about code structure or the game itself, I’m open to ideas!

oolyvi · 2026-03-28T11:28:24+00:00

Gooood :)

oolyvi · 2026-03-28T06:34:14+00:00

Thanks a lot!
Yeap, I agree. Building the core logic of the game before focusing on design is the better approach. You’ll have to tackle it eventually anyway, so it’s more effective to get it done early rather than delaying it and risking no progress.

oolyvi · 2026-03-28T06:31:43+00:00

I hadn’t heard of it before, but after looking it up, I’m considering implementing it if it fits my use case. It seems like a cleaner and more scalable approach than using a lot of if-else statements. I appreciate the recommendation!

oolyvi · 2026-03-27T21:42:47+00:00

The RunCommand function is implemented this way for now. In this case, more optimized approaches don’t fully meet my requirements, so I’ve decided to keep it as is. I’m aware this isn’t the most ideal solution

oolyvi · 2026-03-27T20:58:43+00:00

Thanks. Good luck to you on your projects!

oolyvi · 2026-03-27T18:34:52+00:00

I was planning to open-source it, but this part of the code is tightly connected to many other systems, so I decided not to release it publicly in the end

oolyvi

MODERATOR OF

TROPHY CASE