Everything was going perfect with my game, I heard of the version 134 that the ps5 controller works with it, I went quickly to update and the preview does not work. Same with version 133
I tried version 132 and crashed, I added more Ram to my pc and version 132 runs ok but 133 and 134 no
I will be ok with version 132 but no ps5 controller dpad there :,(
someone could help me? will next releases work for me?
I use a ubuntu 20.04 amd9 40gb ram fully offline
the new version 135, the preview still doesn’t work for me.
in version 133/134 the ram usage doesn’t react at all
the version 135 reacts and increases the usage of ram, but after a few minutes the usage drops as if I never clicked to run a preview
Hi,
Versions 133 and 134 should not be used, as explained in the change log.
Can you give more details about the issue you have with v135?
from gdevelop 88 the preview window takes long to open up, but I used fine even so until version 131
I heard about version 134 that it works with ps5 controller so I tried it, the preview window opens little faster but the window stays black
so then I tried 133 and the preview window loading bar appears, but then crashes
only with version 133 I was abble to make the Developer Tools side window appear, and it when the Preview loading bar stops, the Developer Tools window says “preview disconnected”
I then tried version 132 and was the same error as 133
I increased my RAM to 40gb
135, 134, the same
133 the same
132 works. but no ps5 controller
I did a mega testing
I removed my large backgrounds from the resources, took a while
and without large sprites, it opens.
with my backgrounds it doesn’t.
I am sticking to the 132 until it is fixed, because my background are beautiful and very important for my game
I was supposed to test if this error happen in a intel computer, but I didn’t it yet, because I really want to stay with this fast amd9 one
and also, when click the preview button, the RAM usage starts to increase, when the Preview Window just opens the increase bumps up, but then the RAM go back to normal as if I never clicked to run a Preview, thats how the 133 134 135 crash happens to me, with only 133 showing a loading bar.
As far as your preview not opening, I suppose it could be an issue with your setup, but GDevelop generally doesn’t require anything above 4-8gb for the IDE (and can run with even less), so the amount of ram you have above that truly won’t impact anything.
What will matter is whether or not you meet the minimum WebGL GPU requirements for the current versions of Chromium, as there was an Electron update recently, and it appears Chromium has bumped up minimum requirements for a GPU. If you’re using something like an old APU or integrated graphics it may or may not work, although that is still being investigated.
Just a side note here: GDevelop doesn’t support controllers at all. Are you thinking of the Gamepad extension? Some community extension updates are included in update notes, but are not related to the version they’re notated on.
The gamepad extension has supported the dualsense (ps5 gamepad) for a long time. It has worked since the Dualsense was released. I know this because I use the dualsense as my main test controller.
This is also not related to the version of GDevelop you have. As long as you’re on GD5 you can get the controller extension.
Since the release of the ps5 controller, with the most recent version of the controller extension, the d-pad of the ps5 controller never worked (and I have 3 dualsense and never worked with any)
I tested it with windows and a mac, never fully worked
the ps5 controller only fully worked after version 133/134/135
My pc has the RTX 3060 gpu
the extra RAM thing was due to myself trying everything I could to make it work and only version 132 worked and I am using it now
My linux is updated and so its drivers, its not an old pc
I believe the new electron needs to be better tested and updated to work with mostly computers as possible
To be clear, this isn’t normally a GDevelop controllable decision, if Electron drops support for certain GPUs, and the new electron is needed for other reasons, those other GPUs will no longer be supported.
In this instance it is still unsure whether it is a limited support issue or not, and that is being investigated. However, the potential changes to Chromium/WebGL support would have only impacted older APUs from what has been seen so far, so it is unlikely what is causing your issues. (As in, Electron using a newer chromium dropping older GPU support for WebGL, is unlikely why your preview doesn’t open)
I tested in a different computer a high end gaming intel laptop and gdevelop 135 has the same error
I believe it has a problem related to load high amount o data, games with big sprites like mine.
I hope it get fixed
Can you reproduce the issue in a dummy project that you could share with us, so that we can investigate the issue?
I tested similarly here the way I will describe
in a Linux, use Krita and make a huge Canvas like 7000x7000 or higher and fill it up with scratches, make it bee filesize of 500mb or more
then make multiple copies of it until you have a folder of 20gb
Create a empty game, 3 empty levels, 2 empty Object, then 1 object that as a 1 animation put all this big sprites there by selecting all at once
Use that Object once in any of the levels and try launch a preview
I used a backup of the game, I migrated to version 127 and will stay confortable there until this problem is fixed
Just to clarify, are you saying you have assets over 7000x7000?
Because the engine doesn’t support anything over with an asset file over 2000x2000. This shows up in the engine (an error pops up if you try to import anything at that size or larger) and is in the wiki as well.
If you were using something larger than that before, it was likely not intentional that it worked at all, and unfortunately likely won’t work again in the future. If you mean something else, please provide more details as it’ll be needed for the devs to investigate.
Otherwise, I’ve done testing with numerous images within 2000x2000, as well as have now tested with a project with a single object that has over 100 frames at 200x200 pixel size assets. I am still unable to reproduce this issue.
To be clear, this doesn’t mean that there isn’t an issue, but it does seem very specific to your setup or project, so more info is needed.
omg I had no idea
I am doing this game with Gdevelop since December 2019 and I am finishing just now
I can say abou half of my sprites are above 2000x2000 and a few above 10000xX
I am doing it slowly due to a lot of problems and had Zero idea it got unsupported
I am lost now
Right now I’m working on my game with version127 and its all good all perfect no probems, just no ps5 controller for me.
If have any hope for me or work around for me I will be really Thankfull
Sorry about that
since december 2018***
if the new gdevelop starts working with big sprites
or a extension for ps5 controller compatible with version127 shows up,
please remember me and I will update to have it
I would recommend rethinking how you’re doing sprites.
To put this into context, the largest single sprite in Hollow Knight is only around ~200x200. Some of the larger bosses are 1000x1000 but made with smaller cut up pieces put together via game logic.
Spiritfarer, a game that looks close to hand-drawn animation, has sprites rendered only around 250x250 for their larger characters, with some reaching 500x500 at maximum (from what I can find in their dev logs/around the net). Backgrounds are made up of many smaller sprite pieces put together.
They are drawn at higher resolutions, but then reduced in size before they’re exported from their art tool, then imported into their respective engines.
As far as I’ve ever heard (and can find out on the internet) 2000x2000 for a single sprite is unheard of in 2D game dev.
I don’t know that there’s going to be a workaround for that short or longterm.
like, I really don’t wanna change my game, because if I do change it to fit into a profile, it may turn into something not-unique as it is, and I wanna freedom to use this large sprites, because today it is weird, but in 10 or 20 years it may be “WOOW” because some countries like Japan and Korea has higher numbers of people with 8K and things are going up.
Is it possible to make gdevelop 135+ at least one version with large sprites enabled?
also (I was not able to test in 135+) but in version 127, Gdevelop can play audios only up to Surround 5.1, I started exporting my audios for 7.1 and only “Side Left and Side RIght” plays…
is it related to version 127 X 135+ or is it Gdevelop itself? if it is Gdevelop, is it possible to add Surround 7.1 to it?
this game is my baby, I really need to finish it into Perfection
This isn’t related to GDevelop. It is a hard rendering memory limit for platforms that use web technologies, so pixijs/CT.js/etc all will experience the same thing within limits of WebGL. Some OSes even have smaller limits (older Android and iOS versions max out at 1000x1000).
Heck, even unity has a maximum texture size of 4096x4096 (Without heavy editing and ignoring warnings), and only if the OS supports it within ram limitations.
This limitation is not something that will change within GDevelop itself as it is not a GDevelop specific limitation.
As far as audio, you’d need to investigate the platform you’re using and Howler.js, which is the sound engine used. GDevelop doesn’t appear to have any limits from audio formats, however the only web browser that supports 7.1 natively appears to be Edge. Chromium (the technology/browser used when compiling to desktop or mobile) will just downmix it to 2.0 audio.
but I don’t plan to release my game to be played in a browser
if gdevelop <133 can run a preview of my game, why is it not possible to modify it to the new ones run it?
will my game be able to export to desktop files when I finish?
if gdevelop don’t have limitation for audio, why it doesn’t play 7.1? why will my audio downsize to 2.0 if I don’t plan to play it in a browser?
why only chrome and edge do you use for reference? firefox and tor aren’t good?
Planning to run in a browser doesn’t have anything to do with it. All GDevelop games (and CT.js, etc) use web technologies and WebGL for rendering. Chromium is the web rendering technology used in Electron, the bundling technology that makes GDevelop games into exes.
This really isn’t relevant. The memory limit would impact anyone trying to play your game.
Again, we’re not talking about you playing it in a browser, we’re talking about using browser based technology for rendering. Gdevelop games are exported for use with Electron, which uses Chromium.
I didn’t mention chrome. I mentioned Chromium, which is the web technology used for Electron. And neither of the others support 7.1 natively either.
about the gdevelop 135+ it is totally relevant to me because of the ps5 controller complete support and the advanced touch screen controls
and the memory problem was never a memory problem because I tested it in multiple computers Linux Mac Windows with different configuration and gdevelop 132 run in all of them
also I created a blank project with 135 and it totally accepts sprites as big as 15720, even without the preview opening, the editor shows it and works fine, so it was never because my game is old from gdevelop 87
all I was wanna was the preview to run to use a ps5 controller and have my theatrical audio
I won’t change my game
I will keep going with 127
If I can’t export normally, I will find a way to have my game how I want it (big sprites and theatrical audio)
I won’t bother here anymore.
Please do not confuse the IDE (the scene editor) with the limitations of the renderer (PixiJS and Chromium).
Keep in mind that some form of texture resolutions limits do exist on all platforms and engines, and older hardware will have smaller limits.
However, since these limitations have now been made clear to you, and you are proceeding anyway, I wish you the best of luck and that you find some way to do what your goal is. This thread will now be closed.
Edit with more details:
For the OP, or anyone who may have interest in the technical details-, here’s a more thorough explanation from some quick research:
Max Texture resolution is going to commonly be a combination of 3 things, the maximum VRAM available on the device’s GPU, the maximum texture limit on the renderer, and any memory limit of the operating system.
As an example, for someone with a 3080 GTX with 12GB of ram: The maximum texture it can render in WebGL is 16384x16384 at 32 bits. A single texture after it is decompressed to run in memory at this resolution would take 16384x16384x32 bytes, or 8589934592 bytes, or 8.59 gigabytes of VRAM. Meaning this GPU, if unrestricted could only show 1 texture at this size.
Alternatively, most browsers and web renderers also have a maximum texture/image size limit. Last reported maximum for Chromium is 4096x4096x32 on desktop. (Firefox only allowed 2048x2048 until a year or two ago)
Then there are OS limits, although these are usually restricted to mobile. These vary by OS version so going into specifics, but iOS, for example, has a GPU capable of slightly larger than 5000x5000, but hard limits it to 4096x4096 as recently as data from last year.
No matter what the largest supported texture for any combination of these are (GPU, Renderer, or OS), you will always be limited by the smallest maximum supported of the three.
Even multimillion dollar engines like Unreal are restricted by this, which is why they have had to develop and implement technologies like texture streaming to allow for faster swapping of textures. Keep in mind the above scenario is for the GTX 3080, one of the top of the line GPUs on the market. GPUs with less VRAM or slower VRAM will run into even lower maximums. This is also why when you search around the internet it is generally recommended to never go above 4096x4096x32 even for desktop 3D game development (or 2048x2048 for mobile), to ensure you support the largest market possible.
Hopefully the above details helps other people interested in understanding why games even amazing looking 2D like Hollow Knight and Spiritfarer do not go past these limits.