Banner
Views: 932,829,743
Time:
16 users online: Alice3173, bravetoaster,  brickblock369, Bullymario, codfish1002,  JamesD28, JupiHornet, margot, MarioSonic4life, Paithus,  patcdr, Sevhen, Splat3r, The Central Scrutinizer, TomatoPhalanges, umbreon3209 - Guests: 90 - Bots: 246 Users: 52,067 (2,106 active)
Latest: Graul
Tip: In all types of Kaizo hacks, glitch abuse is encouraged. Check the SMW Glitch List by clicking here.
Not logged in.
Game Maker Studio 1.4 WebM Player (aka the most miserable programming experience in my life)
Forum Index - Sunken Ghost Ship - C3 Museum - Summer 2021 - Game Maker Studio 1.4 WebM Player (aka the most miserable programming experience in my life)
Tags:
Pages: « 1 » Link
What I've been staring at for 2 weeks.
DOWNLOAD

This is a port of Samuel Venable's Game Maker Studio 2 WebM Player extension to Game Maker Studio 1.4. The WebMs are read directly from their files (no conversion to any weird proprietary format needed) and are outputted to a background which can be drawn/maniplulated however you want.

Included is a sample object, room and WebM showing how the extension works and how it's set up. plus you get to see a guy talk to an animal's ass for some reason; it was included with the original extension so don't ask me about it The source code to the original extension can be found here.

However that's not the reason I'm writing this thread. (C3 just so happened to start while I was working on porting this) The main thing I want to share is the sheer utter horror story of me trying to get this thing working. It is unquestionably the most miserable gamedev experience of my whole life. So far.

Oh wow I completely missed this thread. I'm glad I checked it out, this was a good read.

I actually ran into the exact same issue with buffer_set_surface around a year ago at this point and to this date I still haven't bothered to try and make any optimizations, what I did at the time was

Code
        surface_set_target(surface);
        for (var yy = 0; yy < sH; yy++) {
            for (var xx = 0; xx < sW; xx++) {
                var pixel = buffer_read(buffer, buffer_u32);
                draw_set_alpha(((pixel>>24)&$FF)/255);
                draw_point_color(xx, yy, make_colour_rgb((pixel>>16)&$FF, (pixel>>8)&$FF, (pixel>>0)&$FF));
            }
        }
        surface_reset_target();


which is pretty much the same thing you did except with buffer_read instead of your buffer_peek, I wonder if that has any significant performance gains/losses, can't say I ever tried but I wouldn't expect it to either.

The unrolling optimization is interesting, I don't remember if I considered it back when I played around with it, the main issue I see with it is that it only deals with widths that are divisible by 10, which shouldn't be an issue in most cases but it is something you always have to be careful about using it. I'm a bit surprised it gives significant performance gains, I'll have to steal borrow that code for myself huh :p



This thread gave me a different idea though: I recently got into playing around with extensions and tried to do things with window_device(), since you also have access to the buffer which I didn't realize you could do until now, I wonder if one could implement buffer_set_surface directly in C++ and if that would give good results. I feel like it probably should but also the last time I tried something with the D3D9 API was about as much a pain as this and showed even less results lmao

I also didn't realize what background_add/replace and sprite_add/replace did differently, this whole thread gave me a bunch of ideas I want to try now haha.


If I didn't have like 5 other things currently going on I'd love to try and do that, maybe if I find some time before C3 posting ends I'll give it a go.
Yoshiatom's Post
Thanks for reading through this! I was honestly expecting this to be too niche for most people on SMWC to look at #tb{:p}

Originally posted by TheBiob
I actually ran into the exact same issue with buffer_set_surface around a year ago at this point and to this date I still haven't bothered to try and make any optimizations, what I did at the time was (code)

I did try to use buffer_read, but I must have been doing something wrong since it ended up looping through the buffer and drawing the video twice horizontally (even if I halfed the drawn pixels it resulted in a squashed video), it looks like you're doing something slightly different in your code though.

Originally posted by TheBiob
which is pretty much the same thing you did except with buffer_read instead of your buffer_peek, I wonder if that has any significant performance gains/losses, can't say I ever tried but I wouldn't expect it to either.

When looking it up there seems to be some debate over whether buffer_peek or buffer_read is faster, but either way it wasn't enough to make a good perfomance difference for this mess.

Originally posted by TheBiob
The unrolling optimization is interesting, I don't remember if I considered it back when I played around with it, the main issue I see with it is that it only deals with widths that are divisible by 10, which shouldn't be an issue in most cases but it is something you always have to be careful about using it. I'm a bit surprised it gives significant performance gains, I'll have to steal borrow that code for myself huh :p

I was trying to figure how to automaticaly adjust the loop unrolling for different multiples, but by that point I was super burned out I couldn't figure it out. I think Duff's Device should be possible to implement in GML though since switch statements can "fall-through" like C. I don't think you really need to do loop unrolling in GML unless performance is REALLY being tanked by the loop.

Originally posted by TheBiob
This thread gave me a different idea though: I recently got into playing around with extensions and tried to do things with window_device(), since you also have access to the buffer which I didn't realize you could do until now, I wonder if one could implement buffer_set_surface directly in C++ and if that would give good results. I feel like it probably should but also the last time I tried something with the D3D9 API was about as much a pain as this and showed even less results lmao

God I was really hoping someone would have tried to implement buffer_set_surface as an extension while working on this, I'm glad to hear it's a possiblity but I'm sure as hell not going to try doing that myself; I felt out of my depth working on this in general and I feel like I'm sounding like I know a lot more about programming than I actually in this thread lol

Layout by Koopster!

<DeputyBS> I knew it
<DeputyBS> alcarobot is taking over the world through his truck dealership franchise
Honestly, I actually do plan to read all of that, because it happens to hit very close to home. Writing video player integrations for various platforms was actually the very first thing I did when I got my current job, at a time when I was still a total beginner, and it was an absolute pain in the ass, so I know the struggles. That alone makes me very interested in reading this.

For now, though, let me just say kudos for actually making it happen! I'm impressed!

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
(i just wrote all of this already and then accidentally closed the tab, good job me and here we go again)

Originally posted by yoshiatom
I did try to use buffer_read, but I must have been doing something wrong since it ended up looping through the buffer and drawing the video twice horizontally (even if I halfed the drawn pixels it resulted in a squashed video), it looks like you're doing something slightly different in your code though.

The only difference I see is that you first AND and then shift while I shift first and then AND as well as the fact that you use BGR instead of RGB which is, which I still find interesting because buffer_get_surface (which I used in my project) returns it in RGB format so I'd expect buffer_set_surface (if it would work) to do the same. Maybe that's a GMS2 thing.

Originally posted by yoshiatom
I was trying to figure how to automatically adjust the loop unrolling for different multiples, but by that point I was super burned out I couldn't figure it out. I think Duff's Device should be possible to implement in GML though since switch statements can "fall-through" like C. I don't think you really need to do loop unrolling in GML unless performance is REALLY being tanked by the loop.

Oh I completely missed the line about Duff's device, I never actually implemented that and I don't know if GML syntactically allows for that but that would be an interesting fix as well as optimization for it.

Originally posted by yoshiatom
God I was really hoping someone would have tried to implement buffer_set_surface as an extension while working on this, I'm glad to hear it's a possibility but I'm sure as hell not going to try doing that myself; I felt out of my depth working on this in general and I feel like I'm sounding like I know a lot more about programming than I actually in this thread lol


Well, turns out it's possible.

Doing it the naive way of porting the GML loop you have to C++ actually barely increased the performance so it was not as trivial as "C++ = Faster". Fortunately, after looking through the documentation and googling a bunch I found a way that works significantly faster than drawing each pixel individually.

I added an extra dll with my code to the extension and changed the GML to use that to draw it.
Here's the code I ended up using:


I had to swap BGR to RGB while copying the data to the new surface because yeah, why does it return BGR? A simple memcpy worked in my project just fine, this is still performing a lot better though.
(Also, yes, the name of the function is a bit misleading. It's not actually a port of buffer_set_surface it's more of a barebones draw_buffer function so you still have to do surface_set_target to set it up. The code also has no error checking so the buffer and the surface need to be the correct sizes or it will crash)

With these changes I ended up getting the example video from around 6fps to 100fps. Unfortunately bigger WebMs seem to be too much for the code and it just crashed but it works fine for smaller ones. Or maybe it's an encoding issue, I don't know.

The code is also windows only due to the use of window_device() to get access to the low level graphic api gamemaker uses, not sure if uinx/mac have different options for it. For my project that's perfectly fine but for other projects it might not be.
There were also a few comments indicating that creating a plain surface every frame might not be the best for performance but I didn't want to make this post last minute before posting closes and this works so here we are.

So yeah, this was actually a lot of fun and helped me with my project a lot as well, if you want to take a look at the changes, I packed a new version of the extension with my changes, here's a download
Yoshiatom's Post
Originally posted by TheBiob
So yeah, this was actually a lot of fun and helped me with my project a lot as well, if you want to take a look at the changes, I packed a new version of the extension with my changes, here's a download


I don't know if I'm doing something wrong, but after importing this into a fresh project it didn't render the video at all like with my original attempts with buffer_set_surface. (the actual surface was being drawn because I could still do other things with it)

I swear to god if this being caused by the exact same issue where buffer_set_surface doesn't work on some systems for seemingly no reason I'm going to have a birth of cactuses out of my asshole.

also while typing this I accidently typed "buffer" as "suffer" which I'm shocked I didn't think to use as a joke in my OP

Layout by Koopster!

<DeputyBS> I knew it
<DeputyBS> alcarobot is taking over the world through his truck dealership franchise
Originally posted by yoshiatom
I don't know if I'm doing something wrong, but after importing this into a fresh project it didn't render the video at all like with my original attempts with buffer_set_surface. (the actual surface was being drawn because I could still do other things with it)

I swear to god if this being caused by the exact same issue where buffer_set_surface doesn't work on some systems for seemingly no reason I'm going to have a birth of cactuses out of my asshole.

Huh, that would be unfortunate wouldn't it. Unless I'm using it wrong though, buffer_set_surface definitely doesn't work on my machine and the code I wrote does so I'm not sure that's it.
It's always hard to debug when it doesn't happen for myself, I sure if I can do much before posting ends here either but if you're interested I'd love to look into why it doesn't work and maybe find a fix for it.

(Also, what a quote lul)

Originally posted by yoshiatom
also while typing this I accidently typed "buffer" as "suffer" which I'm shocked I didn't think to use as a joke in my OP

That would've been pretty good lmao
Finally got to read all of this.

Originally posted by TheBiob
I had to swap BGR to RGB while copying the data to the new surface because yeah, why does it return BGR? A simple memcpy worked in my project just fine, this is still performing a lot better though.


Does Game Maker 1 support shaders? If so, swapping color channels directly on the GPU should be significantly faster than doing it in the loop, and a pixel shader like that is usually pretty simple to write.

Originally posted by yoshiatom
THE MORAL OF THIS STORY:
Game Maker Studio 1 is utter garbage. If you want to make games, use literally anything else other than the dumpster fire that is GMS1.


This is the bottom line. I once had to jump through like twenty hoops, just to be able to use animated tilemaps in Game Maker 1 without a performance penality. It's hands down one of the worst engines I've ever worked with.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Pages: « 1 » Link
Forum Index - Sunken Ghost Ship - C3 Museum - Summer 2021 - Game Maker Studio 1.4 WebM Player (aka the most miserable programming experience in my life)

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks