Turns out the dual-source blending feature is the ability to return 2 source colors from a fragment shader and running them through the fixed-function blending unit, or something like that.. 🤨
I speak Arabic although rarely and not very well, my dialect is frozen in time from 15 years ago back when I was a teen. When I listen to young native arabs talking about their experiences, it feels to me like the way they express and structure their ideas is different, it resembles how English is structured.
It's as if they found a bridge between the two that I never could. I think this organic convergence with English is not unique & will spread to all modernly educated societies eventually 🤔
Attempted to run AetherSX2 PS2 emulator on the new Amazon Fire HD tablet (MT8183 4xA73 4xA53 and Mali-G72 MP3), on paper the CPU should be sufficient but the emulator shows a notification on startup that double-source blending is not supported by the hardware! and the GPU doesn't even report vulkan support probably because it's missing that blending type 😅 anyway, even with the graphics glitches the tablet didn't run anything I tested at playable speed so, meh 😒
Next insight comes from the cycle of: create new component, init/spawn a test entity by throwing a mass of data into it, then implement new update/draw systems to finally see something.
Parts of that cycle are definitely hurt by the code-based pipeline. Initializing components would greatly benefit from being UI driven rather than be hardcoded in the source.
So perhaps an ideal ECS pipeline would offload as much as it can to UI and pure data and leave the coding for game systems exclusively 🤔
That tendency to create new components led to an explosion in similar components that behave slightly differently: sprite, animated sprite, shadow sprite, isometric sprite, etc
And each type of sprite required a slightly modified drawing system/function.. suffice it to say, ECS so far has been very harsh on code density. I haven't even gotten locomotion to work yet and it's already half way through pico8's token limit! 😯
Another thing I noticed: when I need something to behave slightly differently I have to fight the urge to expand existing components and instead create a new component for it.
Example: shadow is a sprite that draws every other frame, rather than add a flag to the sprite component to do that I created a new shadow-sprite that draws every other frame.
I'm not 100% sure this is a better approach, it just naturally evolved due to the lower cost of creating new components vs modifying existing code
But the first big thing of note is how slow i suddenly was at implementing every single new element. It took me an order of magnitude more time to get that same scene drawn and animated and I havent even done locomotion yet! It feels my brain doesn't yet know how to speak ECS, so things like having an isometric sprite with little spinny fans and an offset flickery shadow took much more careful thinking to get running.
Then I started reimplementing that from scratch using a minimal ECS framework that I developed partially for Love2D a while ago. Did you know pico8 lua lacks the table.* std library?
The lessons began immediately. I had to implement an init script that runs once which is trivial to do directly, but here I implemented it as a system (function) that runs on entities with "init" components killing the entity at the end. There was no way for me to control when the init system runs though..
Putting these isometric sprites together, the results were better than I expected! In a full project, I'd create some automation for rendering models from all required angles then creating initial sprites by scaling down the renders
I started by implementing a small piece directly in pico8 in the way I'd do it if this was a gamejam, through this stage I experimented on creating isometric art by making a rapid model then rendering it from 8 isometric viewpoints then hand drawing 16x16 sprites in pico8 based on the renders. I used wings3d+povray to do these
I feel guilty for pushing ECS as the future of gameplay programming despite the fact I never created a game with it, mainly due to depending on mainstream current engines.
This weekend I wanted to do a small fun pico8 thing to try to learn more about ECS in practice.
Initially ECS looked attractive to me due to the potential of reaching that magical point when a system madeup of small highly specialized parts comes alive with complex behavior that would be difficult to write directly
While watching a short GT7 trailer where the director describes how amazing it's that we are graphically so close to reality now, I began wondering.. what happens after we reach graphics indistinguishable from reality in games? will there be a new goalpost after that? and if there wasn't, does that mean the age of evolving graphics tech and engines will come to an end and focus will shift to content scaling instead from then on.. 🤔
exciting times ahead
After giving it a little bit of thought, I think it's impossible to run PS2 on this because of its GPU, the Vivante GC800 doesn't pack much compared to the VPU1+GIF+GS combo. PSP is out as well due to GPU, and PS1 already runs well through a normal emulator. Perhaps N64 might be a good candidate for utilizing the hardware similarity? ¯\_(ツ)_/¯
I ordered a retro handheld called the RG280V the other day, this thing doesn't have an ARM processor as I thought at first, but a MIPS32 with SIMD extensions! it's a low-power 2-core CPU but this is the same architecture as PS1, PSP, and PS2 Emotion Engine.. which made me wonder, is it possible at all to take advantage of the hardware similarity to run PS2 games on this little thing? the VUs could be emulated by the SIMD extensions, and there is a GPU in there for mincing polygons and pixels 🤔
Today, my mind was blown when I tried the latest unstable build of the playstation 1 misterfpga core created by FPGAzumSpass. I've seen gifs that show rapid dev progress but I didn't realize it got this far! it ran everything I tried beautifully even games that included fmvs. Only SPU and memory card functionality are left and what was considered almost impossible last year becomes reality
Winter works. Great success 👍
I have a sandisk ultrafit 128gb flash that overheats like crazy and starts to periodically halts then dies and disconnects if you transfer large data fast, it got so hot it killed a usb port in a cheap usb-c hub I used 💀
I should probably bin it.. but if I can somehow cool it while writing to it, I can setup batocera & roms on it and as long as I avoid any large transfers it would be usable.
hmm 🤔..💡! it's -7 outside, there is a window next to me and a half dead aluminum usb-c hub
Tested AetherSX2 emulator on my snapdragon 855 phone, this is an emulator built for android using the same codebase as PCSX2. It's not perfect much like its ancestor but the results are amazing!
Until recently, I would've bet consumer android SoCs needed a few more years until they are capable enough to emulate the complex PS2 architecture... yet here we are! 🎮
I recently did a Batocera install on a 64GB USB SSD I have, and it's essentially close to that: direct boot on any x86-64 machine, full access to GPU/sound/networking/bluetooth/etc.. there is an underlying OS but it's completely hidden from the user and you only see the emulation frontend. I tested it on 2 laptops without discreet graphics and a gaming PC with an nvidia GPU and performance is stellar! how fast the thing boots into the frontend put a smile on my face https://batocera.org
Accidentally stumbled on myOS an experimental miniature linux targeting OpenGL/C development https://community.khronos.org/t/myos-miniature-linux-based-opengl-development-system-without-x/47811
I'm very interested in any similar recent attempt to do this? a no-distractions barebones Linux distro with a full drivers set for gpu/sound/input/networking that runs from a ramdisk providing a GCC dev environment and tools. Should be bootable from any x86 machine and provides access to a modern package manager for any additional dev tools/libraries needed 🤩
gamedev, motorbikes, retro computing and post-humanism enthusiast
Mastodon server focused on game development and related topics.