|
Are there any nice tricks to scale down an image in Unity? I want to create a thumbnail of a screenshot for game saves. I can understand a general solution is a pain in the rear end, but I figured making something like that wouldn't be a big deal. Right now, I just read choice pixels from the original image, but it's very coarse.
|
# ? Oct 10, 2016 08:15 |
|
|
# ? Jun 7, 2024 04:48 |
|
Dr Monkeysee posted:I'm having an issue with font-rendering. I'm building a hobby project on top of SDL and using SDL_ttf for font support. So far I'm mostly just testing out various graphical aspects and I'm finding that SDL's font-rendering seems really... shabby. This surprises me because I know SDL is the underlying layer for plenty of games out there and Googling around I haven't been able to find anyone having the same issues I have so maybe I'm just missing something obvious.
|
# ? Oct 10, 2016 09:53 |
|
Rocko Bonaparte posted:Are there any nice tricks to scale down an image in Unity? I want to create a thumbnail of a screenshot for game saves. I can understand a general solution is a pain in the rear end, but I figured making something like that wouldn't be a big deal. Right now, I just read choice pixels from the original image, but it's very coarse. I've usually been really lazy about it and just loaded whatever image onto a sprite and used the scale parameter of the transformation. If you have a target size, I think images have a resize function somewhere, but to read the docs for the forums before coffee. You can probably specify size when loading an image, too.
|
# ? Oct 10, 2016 12:41 |
|
leper khan posted:I've usually been really lazy about it and just loaded whatever image onto a sprite and used the scale parameter of the transformation. If you have a target size, I think images have a resize function somewhere, but to read the docs for the forums before coffee. You can probably specify size when loading an image, too. All I know for sure from the APIs is that Texture2D.Resize() will drop the pixels on the floor. It is just a convenience function to use a texture handle. In all the Unity forums posts I skimmed, it was pretty much somebody pimping their $25 addon or a Wiki link to a multithreaded algorithm to keep it from taking 2 seconds to compute.
|
# ? Oct 10, 2016 15:32 |
|
Dr Monkeysee posted:And finally here's SDL rendering the glyph in Blended mode: I have a feeling you're doing something wrong. It looks like an upscaled version of the 12pt font.
|
# ? Oct 10, 2016 15:37 |
Yeah. When fonts are loaded they're loaded for a specific resolution, and will look wrong if displayed at any other resolution.
|
|
# ? Oct 10, 2016 16:27 |
|
Sdl ttf requires that you specify a size when you load a font. It only looks good at that exact size. I switched to sfml and it is miles better in every way than sdl.
|
# ? Oct 10, 2016 17:51 |
|
Anyone making unity games might be curious to check out the new uber effect we just released: https://github.com/Unity-Technologies/PostProcessing/wiki Should work on unity 5.4.1+. it combines most of the post processing into a few fast passes instead of having each effect as an individual pass. Saves a bunch of ms in the general case.
|
# ? Oct 10, 2016 17:59 |
|
Strumpy posted:Anyone making unity games might be curious to check out the new uber effect we just released: Which is to say: when would you expect this to hit the main branch?
|
# ? Oct 10, 2016 18:39 |
|
Suspicious Dish posted:I have a feeling you're doing something wrong. It looks like an upscaled version of the 12pt font. That's what it looks like to me as well but I'm setting the font size correctly (as far as I can tell). I can post some code after work today. I don't believe I'm doing any scaling, unless something is happening implicitly. It's just load font -> blit glyph to surface -> convert surface to texture and send to renderer.
|
# ? Oct 10, 2016 18:50 |
|
Joda posted:Yeah. When fonts are loaded they're loaded for a specific resolution, and will look wrong if displayed at any other resolution. One thought: this is on a retina screen. I would assume the OS would handle scaling everything seamlessly and if I load a regular old texture using SDL it renders just fine, but is it possible SDL_ttf is reading the DPI incorrectly and rendering for a smaller screen than it thinks it is (thus getting scaled up and looking like crap)? Before posting this last night I search around the web for any issues with SDL_ttf or Freetype with hi-dpi screens but nothing came up.
|
# ? Oct 10, 2016 18:59 |
|
Shalinor posted:... am I imagining things, or are all of those effects also in the category of "haven't actually been incorporated into the main branch yet, they've thus far lived in a separate plugin / experimental only"? I've been running the Amplify set, but those would seem to cover all the same bases. They are official and fully supported, we are just shipping them separate from the main unity install so that we can iterate faster and not be tied to normal release cycles. These are not experimental like the experimental builds (need a separate unity install) as you just put them in your project like an asset store package. We have some work being done to make plugin workflows much easier in Unity, and when that's done they will be shipped via that mechanism. We just want fast iteration time on bug fixes / integrating feedback for the next few months.
|
# ? Oct 10, 2016 19:01 |
|
baby puzzle posted:Sdl ttf requires that you specify a size when you load a font. It only looks good at that exact size. I switched to sfml and it is miles better in every way than sdl. Why do you prefer SFML over SDL?
|
# ? Oct 10, 2016 19:26 |
|
Dr Monkeysee posted:One thought: this is on a retina screen. I would assume the OS would handle scaling everything seamlessly and if I load a regular old texture using SDL it renders just fine, but is it possible SDL_ttf is reading the DPI incorrectly and rendering for a smaller screen than it thinks it is (thus getting scaled up and looking like crap)? When you said you were doing this on mac, the retina screen was the first thing that came to my mind. iirc, the resolution issue is handled at the OS level, not app -- in that the apps see things like their size at non-retina scale -- so SDL could think it's running at non-retina resolution. I don't know more detailed implementation info, though, and could be wrong on some of that.
|
# ? Oct 10, 2016 19:26 |
|
Dr Monkeysee posted:Why do you prefer SFML over SDL? Well I need to render in a separate thread and it seems sdl can't do that. Sdl has to render text to an intermediate texture but sfml can draw text on any draw target pretty quickly at any size. Changing font size in sdl requires loading a whole new font instance.
|
# ? Oct 10, 2016 20:04 |
|
Dr Monkeysee posted:One thought: this is on a retina screen. I would assume the OS would handle scaling everything seamlessly and if I load a regular old texture using SDL it renders just fine, but is it possible SDL_ttf is reading the DPI incorrectly and rendering for a smaller screen than it thinks it is (thus getting scaled up and looking like crap)? You can also try setting SDL_WINDOW_ALLOW_HIGHDPI on your window and see if that makes a difference.
|
# ? Oct 10, 2016 20:31 |
|
SupSuper posted:AFAIK SDL_ttf uses a fixed DPI, I would play around with the sizes and see if retina is resizing the window in post or something. I played around with HIGHDPI a while back and iirc it scaled everything to physical pixels instead of logical pixels so everything was 1/4 the correct size but I'll try it again. The fact that basically nothing comes up online about this issue tells me either no one's using SDL on modern DPI screens (sounds highly unlikely) or I'm not tripping some obvious setting like this.
|
# ? Oct 10, 2016 21:16 |
|
Dr Monkeysee posted:...no one's using SDL on modern DPI screens (sounds highly unlikely)... If the issue is retina, then it's purely a Mac issue, in which case I don't think that's a safe assumption. Remember that a retina laptop screen is more than 1080 (2304x1440, 2560x1600, and 2880x1800), and Windows support of resolutions higher than that has been iffy; in Windows land, you only see really high end gaming laptops going above 1080.
|
# ? Oct 10, 2016 22:22 |
|
Dr Monkeysee posted:I played around with HIGHDPI a while back and iirc it scaled everything to physical pixels instead of logical pixels so everything was 1/4 the correct size but I'll try it again. Yes. You need to use SDL_GetDrawableSize to find our your real dimensions. You asked for it to be able to handle retina displays yourself. You're using the compat mode path for Retina. The one where your app isn't Retina-aware. Apple will do some amount of vector graphics scaling for you, but since your app, through FreeType, renders glyph data into a texture, Apple can't magically adjust those sizes for you.
|
# ? Oct 10, 2016 22:49 |
|
Suspicious Dish posted:Yes. You need to use SDL_GetDrawableSize to find our your real dimensions. You asked for it to be able to handle retina displays yourself. Is there a combination of settings that would handle this elegantly or will I need to deal with scaling based on drawable size throughout the app? e.g. will I need to render everything at 4x myself? Last I looked at this the HIGHDPI setting was paired with a plist setting who's name escapes me. I'll try that when I get a chance but it sounds like I'll have to care about scaling explicitly in at least some places?
|
# ? Oct 10, 2016 23:31 |
|
Alright folks I got a chance to play with this a bit. As you all figured to get true hidpi I had to set SDL_WINDOW_ALLOW_HIGHDPI. Some of the documentation *strongly* suggests I need to set NSHighResolutionCapable in the app plist file as well but Apple's documentation seems to suggest that's optional these days and it seemed to work either way. Anyway the upshot is just setting that flag everything renders at 1/4 its size. So I *do* have to handle scaling myself. Calling SDL_GL_GetDrawableSize and comparing that to the given window size gives me the scaling factor (though as expected it's 2x this is a nice way to calculate it dynamically). Once I know that I have to: 1) adjust all SDL_Rect positioning by that factor 2) scale texture destination rects by that factor and 3) multiply the desired font size by that factor So it's... sorta intrusive but some clever wrapping of SDL will probably mitigate the pain points. Here's the original Monaco "A" at 24pt as rendered by the OS: And here's SDL's blended Monaco "A" at the "scaled" point size (i.e. 48pt): I think I can live with that! It's sort of a bummer I have to handle the scaling myself but at least I have something workable. Thanks for your help, everybody!
|
# ? Oct 11, 2016 06:15 |
|
The remaining bold-ish stuff is actually incorrect gamma. SDL_ttf doesn't do any gamma correction, you should do that yourself in your shaders. See the note here: https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Render_Glyph
|
# ? Oct 11, 2016 07:51 |
|
That time when you realize your engine does relevant things and you replace a few dozen lines of buggy garbage with a single function call.
|
# ? Oct 11, 2016 16:31 |
|
Suspicious Dish posted:The remaining bold-ish stuff is actually incorrect gamma. SDL_ttf doesn't do any gamma correction, you should do that yourself in your shaders. Man this stuff is complicated. Would it be worth it to drop down to freetype directly instead of using SDL_ttf? edit: also how would this apply when generating, say, a sprite sheet where the bg color used for proper aliasing is just a placeholder for transparency? seems like it would make for artifacty glyphs when rendered against arbitrary backgrounds since they were blended with the wrong color. VVV Dr Monkeysee fucked around with this message at 19:16 on Oct 11, 2016 |
# ? Oct 11, 2016 18:54 |
|
Eh, it's not that important. Just stick with what you have for now. I was just explaining why it looked different, not suggesting you to fix it. Most games don't bother getting this stuff 100% right because it's expensive, performance wise, and actually doesn't matter.
|
# ? Oct 11, 2016 19:04 |
|
As a minor followup to this I discovered I can remove a lot of the SDL_Rect coordinate janitoring by setting the scale factor using SDL_RenderSetScale to 2x. This means any standard coordinates and rendering still maps to logical pixels and scales properly (e.g. giving an x,y of 400,50 puts it where you would expect 400,50 would go instead of having to actually use 800,100). The only remaining piece is the font still needs to be loaded at twice the desired point size and any textures generated from that font need to have their destination rectangle's width and height halved before rendering (or you temporarily reset the renderer scale back to 1x but the former is clearer to me). In short: the SDL OpenGL rendering layer as a whole seems to handle scaling just fine as long as you tell it the scale factor and you just have to fool SDL_ttf.
|
# ? Oct 12, 2016 05:39 |
|
Twelve days of fury so far: http://test.elimination.zone/login.php Just gotta get doors working (opening and closing at request of room on either side) and ... then I get to do art. At least I don't have to mess with draw order due to my Nɪɴᴇ Cɪʀᴄʟᴇs Oғ Cᴀɴᴠᴀs Hᴇʟʟ and the drop shadow stacking is going to be loving fabulous.
|
# ? Oct 12, 2016 22:15 |
Not sure what I'm doing but I found your dot or something! My movement was really not-smooth for some reason. I went in the direction I pressed but had lots of very tiny jumpiness. You should hop in the IRC to get people to test it: irc://irc.synirc.org/sagamedev And that Twitch login support is rad!
|
|
# ? Oct 12, 2016 22:34 |
|
Polio Vax Scene posted:Not sure what I'm doing but I found your dot or something! I think it takes issue with Chrome 52 by the way. 53 is okay. Firefox seems solid, which is kinda bizarre. Polio Vax Scene posted:And that Twitch login support is rad! Ranzear fucked around with this message at 22:58 on Oct 12, 2016 |
# ? Oct 12, 2016 22:48 |
|
Polio Vax Scene posted:My movement was really not-smooth for some reason. I went in the direction I pressed but had lots of very tiny jumpiness.
|
# ? Oct 13, 2016 00:00 |
|
roomforthetuna posted:camera freaking out in I think one-frame-lagged positioning, resulting in the camera jumping up when the 'me' dot jumped down and vice-versa. Good catch. The view update was running before the room step. Noticed when trying to fix room transition sliding.
|
# ? Oct 13, 2016 12:05 |
|
I'm dragging and old question out of the ditch for Unity 5: Have there been any advances in baked lighting to easily handle things like light switches? It still looks like Unity 5 just bakes everything in one hit and doesn't have a notion of handling things like light switches. If this is true, what's the latest Cool Kid plugin to buy for that kind of thing? I'm basically looking back to the Quake/Half-Life days where it could bake in the effect of all the different light switches and I want to be able to do similar.
|
# ? Oct 13, 2016 20:37 |
|
Made some improvements to my animation creation tool so thought i'd share this move hot off the presses. The "clit butt". https://www.youtube.com/watch?v=BHogevNmpr0 Edit: slightly less stupid demo awesomeolion fucked around with this message at 22:57 on Oct 13, 2016 |
# ? Oct 13, 2016 22:48 |
|
Rocko Bonaparte posted:I'm dragging and old question out of the ditch for Unity 5: Have there been any advances in baked lighting to easily handle things like light switches? It still looks like Unity 5 just bakes everything in one hit and doesn't have a notion of handling things like light switches. If this is true, what's the latest Cool Kid plugin to buy for that kind of thing? Light baking works for what it is, it's just - monolithic. Very not useful to us (procgen), so we went hard dynamic lighting, and found plugins to make that not look poo poo. I wish it at least allowed baking SH in a room, then saving that off as a prefab to spawn elsewhere later, but nupe.
|
# ? Oct 13, 2016 23:06 |
|
Shalinor posted:Short answer, no. There are ways of hacking that, but they're beyond the pale in terms of reasonable things to do. I've seen rumblings that they're going to remove the bake system and replace it with a whole other new one. Edit: And it looks like the asset I was thinking of trying never made it to Unity 5, and I don't even know if it would have done what I wanted anyways. Huzzah. Rocko Bonaparte fucked around with this message at 03:35 on Oct 14, 2016 |
# ? Oct 13, 2016 23:17 |
|
Rocko Bonaparte posted:I'm dragging and old question out of the ditch for Unity 5: Have there been any advances in baked lighting to easily handle things like light switches? It still looks like Unity 5 just bakes everything in one hit and doesn't have a notion of handling things like light switches. If this is true, what's the latest Cool Kid plugin to buy for that kind of thing?
|
# ? Oct 14, 2016 04:16 |
|
Is there a good guide on unity lighting anyway? I desperately need one.
|
# ? Oct 14, 2016 04:20 |
|
roomforthetuna posted:Could you just bake the entire level repeatedly, and switch out map-objects in their entirety? Something to the effect, but we're talking maybe 8 different lights in a house or something with overlapping reach.
|
# ? Oct 14, 2016 04:28 |
|
I wasn't really sure if there was a better place to ask this, but are there any good documentaries, or even interesting books and/or lectures on level design that people could recommend? I was thinking about Dishonored the other day, and how the whole process works. Do they take stock of the player powers first and then build to that? To what degree is this stuff mapped and flowcharted when it's properly thought out, etc. The whole thing really fascinates me.
|
# ? Oct 14, 2016 08:16 |
|
|
# ? Jun 7, 2024 04:48 |
|
I haven't watched these but looking in the GDC vault I see two freely watchable talks about dishonored: http://www.gdcvault.com/play/1018090/World-of-Dishonored-Raising http://www.gdcvault.com/play/1018062/Empowering-the-Player-in-a
|
# ? Oct 14, 2016 09:05 |