Jump to content

historic_bruno

WFG Retired
  • Posts

    2.755
  • Joined

  • Last visited

  • Days Won

    47

Posts posted by historic_bruno

  1. Indeed that was the problem, once I built Atlas UI with wxWidgets using XP compatibility, it worked fine on my XP SP3 laptop. I don't have admin access to the autobuilder currently and it's well past the release date by now, but we can discuss whether to repackage the Windows installer or not.

  2. The really weird thing is, I have never had this problem before with any of the previous alphas on that machine. It sounds like this problem is the definition of bizarre.

    We changed the compiler used to build the release on Windows to a newer version, so it's not extremely surprising to have these issues, XP support is slowly dying since last year.
  3. I'm thinking of adding a config option to toggle SDL2's real/fake fullscreen mode. There are numerous bugs related to fullscreen, but I can't reproduce most of them and there's no easy way to test as changing this requires a rebuild.

  4. Thanks for troubleshooting that, Sander :) I had wrongly assumed that all the textures were handled the same way, but fonts are a strange exception. I don't know why the texture type is stored in the metadata instead of using the properties from the PNG image. One solution is to not convert all grayscale images to RGB (fonts might be the only such textures we have now), which I added as a workaround for grayscale PNG loading, but now that I test, #1640 no longer occurs for me. I'll continue testing.

  5. Thanks for the report! We need some more info.

    How big is the difference, a few pixels or more? I have seen a cursor offset bug on OS X, but not yet on Windows.

    Do you start the game in fullscreen mode? Is the cursor offset from the start of the game? What happens if you switch to windowed mode (Alt+Enter)?

    Also, please attach the system_info.txt log from the game's log folder.

  6. Minor improvement: the engine now supports more types of PNGs including grayscale and indexed color, this can reduce our texture size in SVN. For example, ptol_struct_spec.png saved as grayscale would be 1.57MB instead of 2.47MB (it would be a waste to only commit this conversion though, so I don't recommend it, but for future modifications we might as well). It shouldn't make any difference for the releases since we convert all the textures to DDS anyway, but it's nicer for modders to not have to worry about what kind of PNG the game accepts :)

    • Like 5
  7. I keep getting the following error, even after several seemingly successful attempts at installing Alpha 18. The really annoying thing is I have successfully installed Alpha 18 on one of my computers.

    pyrogenesis.exe - Entry Point Not Found

    The procedure entry point GetLogicalProcessorInformation could not be located in the dynamic link library KERNEL32.dll.

    Which version of Windows are you using? Is it pre-XP SP3 by chance?
  8. - AO factor that is calculated as multiplied mode!

    Right now I think it's overlayed?? The thing is that AO now needs a neutral grey where we don't want shadows, anything over mid-gray would make the model to be brighter than it should, and that's not very intuitive/useful.

    The common practice is to have a greyscale image, where the full white doesn't affect the texture at all, and full dark makes the texture almost black.

    This is very easy to change, here is the current AO calculation in the model_common.fs shader:

    vec3 ao = texture2D(aoTex, v_tex2).rrr;ao = mix(vec3(1.0), ao * 2.0, effectSettings.w);ambColor *= ao;
    So it is interpolating between 1 and twice the AO value according to the effect parameters in the material. That result is then multiplied with the previously calculated ambient color. I think you could even open that shader in Notepad++ (even while the game is running) and experimentally modify those lines, e.g. taking out the "ao = mix(vec3(1.0), ao * 2.0, effectSettings.w);" line.
    • Like 2
  9. Hi guys. I don't think berry bush need recolored if terrains reworked.

    Here, I take stan's terrains and add more variaton and color edits and spec maps and yadda yada. I think game does not need to get rid of the highly detailed terrains, but what I think the game need to do is use those high def terrains for punches of detail, like terrain eyecandy. Most of the map or the "base" terrain would be a more muted and less contrast terrain or set of terrains as you see here.

    You see the "bushy" terrains still exist, but more like eye candy:

    That looks quite nice! It really helps the game objects to stand out. I'd love to hear what Enrique, Pureon, and others think of it. Also would a side-by-side comparison be possible?

    • Like 1
  10. Well, this should be interesting. I am not even sure I will be able to play this alpha, since the last alpha didn't seem to work for me. I could start the game, and the flickering of the main menu foreground I had been experiencing on one of my computers had been fixed, but matches refused to work.

    Was that problem reported? If you have an older integrated Intel GPU, it might have been a certain crash that was fixed for A18. But please report the problem if it still occurs.
  11. Also, as a side note, exchanging the provided OpenAL DLL with the latest stable OpenAL Soft 32-bit DLL (renamed to OpenAL32.dll to match the DLL being replaced) also allowed the game to run properly.

    That's good to know! I'll update to the latest OpenAL Soft for the next release :) Edit: created a ticket for that: http://trac.wildfiregames.com/ticket/3100

    I have included all log files generated by the game as attachments - which, unfortunately, do not seem to include any crash information regarding the included OpenAL DLL.

    There is no crashlog.dmp or crashlog.txt in the log folder? Odd...
  12. One specific point I had trouble with was finding the bushes with the berries on the mainland map. Everything seems to be the same color in the vegetation. This could probably be improved with a few tweaks in the colors of the surrounding vegetation?

    I think that goes back to the valid point being made here, which is that gameplay things get lost in purely decorative things like terrain texture. Apart from modifying the terrains, maybe fruit trees and berry bushes should have larger, more exaggerated fruit to be visible from a distance. The important thing really isn't how great they look or their accuracy, but that the player sees them and instantly thinks "fruit, I can forage those". Side by side, I can't tell much difference between our apple trees and plain wood trees.
    • Like 2
  13. What I got fiddling around:

    It's kind of a hack right now but if you like the effect I can make it work better and put it in-game after A18 is released.

    Current system can tint the skybox so it looks perhaps more realistic (could probably be made to only color rays that look towards the ground). I also use an optional fresnel so you can make it fully chrome or only reflective at sharper angles.

    Edit: yup. Can probably look right on maps where terrain won't change color much.

    Interesting! I guess it doesn't take into account units, structures, actual terrain, so it would have to be used very carefully. Looking at the bottom left screenshot, it would be strange if there was a larger unit, structure, or mountain next to the building but not reflected on its shiny roof. Would it be feasible to at least map terrain, since ours is static?
  14. What happened to these terrains.................

    The first two screenshots are just pre-release eye candy, I believe, to make something that looked impressive but wasn't exactly practical, possibly for trailers - thus the heavy use of alpha grass textures (need someone who was around back then to comment). The third is a much more primitive state of the game, you can tell from the models.

    One thing is the lighting model of the engine has changed since then, that doesn't change the source textures obviously, but I think if you loaded the same maps, models and textures in the engine today, they would look different (better or worse, I can't say). Even now, if you set the renderer to fixed function vs. shader it looks very different, similarly if you have minimal graphics options enabled vs. maximum. So we need to tweak the rendering or the textures themselves, perhaps both. I remember there were quite a bit of lighting adjustments required for the changes around ~2012, it doesn't look the same and it may be brighter in general.

    Finally, you could delve into SVN history and find the terrain textures from that time period and see if they are different, how they changed. You could even install one of the old alpha/pre-alphas from that era - much better than screenshots.

    • Like 2
  15. Great perspective Enrique, can you make a list of features the artists would most want from the engine? It sounds like you have a few in mind already, but if they aren't formally documented (with Trac ticket, design discussion, meeting topics, etc.) I'm afraid they will never happen. The more specifics, the better. Except wraitii and Philip, most of the programmers don't really think about that stuff, so it's good to have this feedback for planning. We should also have more artist involvement in the staff meetings for that reason.

    • Like 5
×
×
  • Create New...