This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
661
General ENIGMA / Re: Help wanted - Please help me test a fix to ENIGMA's font problem
« on: June 04, 2014, 04:40:37 am »Quote
Any chance that the one man ENIGMA team has it wrong and the multi-billion dollar companies aren't selling buggy GFX cards?It's not about a bug, it's about a differences between the GPU's. So it would be useful to know what they suggest as a fix.
662
General ENIGMA / Re: Help wanted - Please help me test a fix to ENIGMA's font problem
« on: June 04, 2014, 03:55:00 am »Quote
Yes I fully agree, but I don't know anybody personally with an AMD card and all my systems and old gfx cards I have are NVIDIA. The only thing AMD I used was CPU. Now I use Intel CPUs.Just tested on laptop's AMD mobility Radeon HD 5000 and it works fine both without and with the fix.
Quote
I agree with you, unless someone used a script to detect in their game to reinit their resources but that would be a pain too.We can make a function that returns whether you need to reload resource or not. But I would want this to be automatic in some way.
Quote
How come this is a non issue with D3D games I play, going windows to FS, never had this issue, is it because games have their own reinit routines ?Yes, because they do all this resource reloading. I always wandered playing CS:S in about 2005 why it sometimes take 20 seconds to alt+tab back into the game. I could hear the sound, but the display was black for a while. I turns out DX just deleted all graphics resources from memory. Sound is unaffected, because it's a different system.
Quote
Would there be any advantages of using DX9 over GL for a game in ENIGMA ?I don't think so. GL is the main system and is the most developed. DX was only made my one person - Robert. I don't think anyone else has ever made a commit in DX. It's possible that DX will be slightly faster than GL1 and maybe GL3, but that's about it. From functionality perspective they are both about equal and GL slightly ahead. From bug perspective GL could have a little less.
Quote
I still can't fucking believe this, moving the projection it is acting like you are moving the texture matrix. This just, should not be happening! It makes no sense.
Quote
But also, we need to look for finding a real fix to this. I am stumped by this and I don't understand why the issues are horizontal and not vertical.I guess it's not the texture matrix (or more precisely UV coords), but the vertices itself. And they are vertical as well, but they show up only at different situations (vertically scrolling background).
Quote
You mentioned something about padding, won't that use up more VRAM ?Depends on the font. All textures in ENIGMA are power of two. That means if you have a 72x72 sprite, then in reality it's 128x128 in VRAM. Right now the default font uses about 60 percent of the texture. So if we add 1px padding, then the texture won't become larger and won't take more VRAM. But for larger fonts and more glyphs it would potentially make it roll over to more vram. LGM could maybe show a preview of the texture and show it's size. It would useful.
Also, did you have this issue in GL3 as well? And does this fix it?
663
General ENIGMA / Re: Help wanted - Please help me test a fix to ENIGMA's font problem
« on: June 03, 2014, 04:02:41 pm »
Works for me too. Geforce 660Ti, Win8.1, driver 337.88. We need AMD people to test this. Also, we should make sure also no other graphical anomalies appear, like texture scrolling bug. In the example horizontal scroll looks fine. Is vertical scroll fine as well? And is there no 1 pixel boarder top/bottom of the screen? Because when I tried to fix an off-by-one error in rendering when I fixed one thing, another broke. So I ended up not fixing it. Maybe this will fix it as well. Mathematically this fix helps with rounding, but it's weird that only x needs to be changed. Would make more sense if both x and y be 0.01.
edit: Was just thinking about the fix and fixing it for packed resources in .exe it should be easy, but external resources could be a pain. If someone doesn't know, the reason DX doesn't render anything after fullscreen or after alt+tab, is because it has destroyed the context. Basically it has disconnected the device (GPU) and deleted all resources. Which means you have to reinit the device and reload all resources. Reloading stuff inside the .exe shouldn't be hard, but loading external resources will be harder, as you load them yourself, and we don't store things like paths or anything else. Even if we did store paths, there is a possibility the resource doesn't even exist anymore (if it was extracted from a zip and put in temporary location, for example). So for external resources it's possible we will have to push this onto the user. Or store a copy in RAM all the time. In this regard GL is a lot better. It also explains why sometimes alt+tab outside a game takes freaking 25 seconds. While in OGL games it is instantaneous. That is why you should use GL on Windows as well. Some game engines are becoming exclusively GL, like id Tech engine (Doom3, Rage, Wolfeinsten). Source actually works faster on Windows when running on GL (http://blogs.valvesoftware.com/linux/faster-zombies/).
Quote
This until anybody else comes with a better idea that is works fully 100% not just partial and yields the same good results with everybody. I'm aiming for at least AMD and NVIDIA good results on these. Right now this is a band aid solution since ENIGMA is not going to get any major fixing anytime soon in this life cycle. Some devs keep on bashing the fix idea, so come up with a better idea then or accept it as a temporary fix. This is fucked up ! First I get given tons of offsets to play with and then it's out of the question and mentioned they would not use that method of fix. LOL ! Whilst the devs keep on inflating their egos and dreaming of 20 years from now when ENIGMA will draw fonts properly on all GPU types, I in the meantime will use a fix that works for me and everyone and does not have any adverse effects (proof is in the pudding so far!!!).You keep being emotional like a girl on a period. You didn't even mention the d3d_set_projection_ortho(0.01,0,room_width,room_height,0) fix in the previous topic. So when exactly was the place when no one wanted that solution? And when did someone said that we won't apply a "band aid" solution? We, just like you, just acknowledge that quick hacks are not the best solutions, but we don't dismiss them. If it works, then it will be applied. ENIGMA has quick fixes in many places in the sourcecode already. So just chill the fuck out. What we DON'T want to apply is a fix that works for you, but breaks shit for others. That is what the previous topic was all about. We tried offsets, we tried rounding and both worked for some and not for others. And this experimentation is how these things get fixed. If you didn't have the patience to do so, then you could of just stopped. No reason to whine about it.
Quote
I would have used DX9 but DX9 is broken too, GENIUS, whoever tested it did not think it was necessary to hit F4 and see if full screen works. oh well, My C++ skill set is not up to par to fix it and never will So until then I have to use OPENGL........We don't test everything. Most of the time only certain examples are tested to see if nothing backwards compatible breaks. In this case it's not even broken, it's just not implemented. The fact that it took 1.5 years for someone to report it kind of shows how little that "feature" was used. I for one, never use full screen. So I didn't notice. Probably is quite trivial to fix though.
edit: Was just thinking about the fix and fixing it for packed resources in .exe it should be easy, but external resources could be a pain. If someone doesn't know, the reason DX doesn't render anything after fullscreen or after alt+tab, is because it has destroyed the context. Basically it has disconnected the device (GPU) and deleted all resources. Which means you have to reinit the device and reload all resources. Reloading stuff inside the .exe shouldn't be hard, but loading external resources will be harder, as you load them yourself, and we don't store things like paths or anything else. Even if we did store paths, there is a possibility the resource doesn't even exist anymore (if it was extracted from a zip and put in temporary location, for example). So for external resources it's possible we will have to push this onto the user. Or store a copy in RAM all the time. In this regard GL is a lot better. It also explains why sometimes alt+tab outside a game takes freaking 25 seconds. While in OGL games it is instantaneous. That is why you should use GL on Windows as well. Some game engines are becoming exclusively GL, like id Tech engine (Doom3, Rage, Wolfeinsten). Source actually works faster on Windows when running on GL (http://blogs.valvesoftware.com/linux/faster-zombies/).
664
Issues Help Desk / Re: Fonts display glitch / Borders / Scrolling glitches
« on: June 02, 2014, 05:13:09 pm »Quote
Very confused here, Robert seems to suggest that everyone complains when offsets are present, and that I am the only one having issues with or without offsets, so by that I am to understand that nobody has any issues with fonts. I find that really difficult to digest because I tried this shit on different systems and all behaved the same way.I do have that "111111" rendering problem. But that's about it. Most of the text (especially when defining custom font) looks fine. But I also want to get to the bottom of this rendering nonsense, because it is also the reason why surfaces rendered off-by-one. But I also have tried many values and haven't find one which works for all. But I don't see the text problems you described earlier.
665
Issues Help Desk / Re: instance_deactivate_region crashes the application
« on: June 01, 2014, 01:10:53 pm »
I think it does create a dummy instance. But it still sucks that you could technically disable the dummy instance and you wouldn't be able to enable it or free it. Thus creating a memory leak. Only by making an exception for that dummy instance would it work correctly.
666
General ENIGMA / Re: ENIGMA on Sourceforge
« on: June 01, 2014, 01:06:58 pm »Quote
There's no reason to use all, true but people keep downloading from sourceforge since the project's page is alive and the downloads function, and those people see a project with 3 years without an update, since nowhere it says you should go elsewere to download the most recent version.The only thing we should maybe do is remove that sourceforge site. But hosting on multiple ones is stupid. They are not actually meant for people to download or popularize the "product" from. They are for developing the "product". So it's version control, not distribution or marketing. And for source version control we use GitHub.
667
Issues Help Desk / Re: >:( objects nowhere to be seen
« on: May 28, 2014, 03:11:23 pm »
Have you tried any examples that are known to work? Try something from EDC.
668
Issues Help Desk / Re: Font rendering/text/sprites/scrol/EVERYTHING is broken ! (Hopeless, no solution)
« on: May 28, 2014, 04:33:34 am »Quote
GLScreen would = 0.375 BUT visually if I do 0.375 for d3d + model view in GLMatrix, it did not work....Knowing some kind of hack to fix it is not enough, we need to figure out why it is happening. Right now your fix kind of denies logic, but we will check and see what could be the reason. Sadly, neither I or Robert can replicate your problems, so I cannot easily test all of that myself.
only worked if I did 0.00/0.00 d3d + 0.375 GL MODEL + 0.375 inside the game through the EDL function !
Quote
Is this really related to a rounding issue, I don't think so, because the rounding alone or rounding + offset trick as suggested and tried (Yes I did do it and yes as shown) did not have ANY effect on anything.As Robert said, it probably is because of rounding whatever you do. Because rasterization operation on the GPU involved multiplication of floating point matrices with vertex positions. If your vertex positions is something else than 0,0, then you probably will have some kind of round issues regardless. But that is why we test a lot of things. I personally think that another good thing to check would be texture coordinates. I think a problem could be precision issues with that, as the position of the glyphs are correct right? It's just that you see lines and malformed letters? Because then it should be a texture problem. Even gaps between tiled images could technically be a texture problem, but they usually are connected with vertex positions.
Quote
Ok well my future games done in ENIGMA will require an NVIDIA card, I already have code to check for that - problem solved.Also, no need to get emotional. We appreciate your testing and it is slowly getting us on the right track. It's just that we need to properly fix it, and doing it trough "magic" isn't something we want to do. And the fact that we cannot replicate the problem also hurts us. So we already determined that it's not just the AMD/NVIDIA issue, as I have Nvidia, Robert has ATI and none of us can replicate these problems.
Maybe later release an exact .egm that has the example you experience the problems in. I will test on an AMD laptop and Nvidia GPU.
669
Issues Help Desk / Re: Font rendering/text/sprites/scrol/EVERYTHING is broken ! (Hopeless, no solution)
« on: May 28, 2014, 03:40:03 am »Quote
Take a closer look at the clear_view function, do you see anything wrong with what you are suggesting? clear_view only uses x and y one time, when calling the ortho function, so it should make no difference translating it there or in the ortho function.It does change things depending on what was done previously. Darkstar, did you really change this line?:
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L111
or did you change this?:
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L116
Quote
In addition I also edited GLScreen.cppIt should mean you actually have the equivalent of x+=0.375, y+=0.375 in:
and added the same line as shown below.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L111
and 0.1875 for model view on line:
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/OpenGL1/GLmatrix.cpp#L128
670
Issues Help Desk / Re: Font rendering/text/sprites/scrol/EVERYTHING is broken ! (Hopeless, no solution)
« on: May 27, 2014, 04:51:16 pm »Quote
I believe I know why this error, so I justThat actually didn't do what I posted, it does what you did before. This would do what I posted:
Code: [Select]
x=round(x+0.5); y=round(y+0.5);
vertices.push_back(x); vertices.push_back(y);
But I also don't think that would change much, because the screenshots you posted show something very peculiar. The first screenshot has two intensities, meaning there are different alpha channels in the texture. If you have AA set to None (as that is for the default font anyway), then you shouldn't see that.I just tested on my nvidia 660ti with newest drivers and the text is slightly buggy with default font in GL1 and GL3 (almost like before, maybe slightly worse). DX9 looks fine with default font. With a custom font GL1, GL3 and DX9 looks fine. So I cannot replicate your problems with an nvidia card and newest drivers.
Can you also try downloading the newest ENIGMA installer and try that from scratch? It's possible you have changed something somewhere previously and that causes the problems now. I don't really have much ideas on what causes this for you.
671
Issues Help Desk / Re: Font rendering/text/sprites/scrol/EVERYTHING is broken ! (Hopeless, no solution)
« on: May 27, 2014, 05:50:14 am »Quote
Or you could try doing what it was that I actually suggested.He could also try:
vertices.push_back(round(x)); vertices.push_back(round(y));
and...
vertices.push_back(round(x)+0.5f); vertices.push_back(round(y)+0.5f);
Code: [Select]
vertices.push_back(round(x+0.5f)); vertices.push_back(round(y+0.5f));
For me everything works fine on Nvidia for now. Will test it at evening with even newer driver (Nvidia released it yesterday or something).
There has been a problem with texture coordinates in text though for a while. I think LGM packs them too tightly and so lines from other characters are sometimes visible (rarely though and only in certain fonts). Especially when interpolation is on. I think we should try adding texture atlas and while doing that rewamp most of the texturing for more consistent results.
672
Issues Help Desk / Re: room_set functions not implemented in ENIGMA????
« on: May 27, 2014, 05:38:28 am »Quote
Yeah, I have noticed a few things 'off' in the half hour that I have been playing with ENIGMA.In this case though, everything is fine. Those functions work just fine. It's just that you have to restart the room for them to take effect (as that is how GM implemented them). If you want to change something on the fly, then use background_index, view_hport etc. So instead of functions you can use built-in variables. They take effect immediately.
So again, read the manual/s: http://docs.yoyogames.com/source/dadiospice/002_reference/rooms/room_set_background.html
Quote
With this function you can set a background for a room (except the current one), with all the same property options that you can find in the room editor like horizontal speed and horizontal or vertical tiling.
673
Off-Topic / Re: Unity Web Player
« on: May 26, 2014, 01:58:01 pm »Quote
Also note that I specifically said this:And I agree with that the performance is very acceptable for games. The topic was basically on how HTML5/JS games are slow, while "native" variants like custom plugins or Java is faster. I just wanted to explain on how that is not really the case. If you run something in a browser, then it is very unlikely you will have more performance than HTML5/JS these days. Custom plugin that basically runs a compiled executable (just like YYG plugin did, which was basically an "shell_execute()") isn't the best option as well, as people are less likely to install plugins just to play a game (maybe just for a few minutes to test it out) and there is a large development overhead involved (more testing, more bugs etc.), while the performance benefit could end up being minimal.
674
Off-Topic / Re: Unity Web Player
« on: May 26, 2014, 01:33:02 pm »Quote
Interesting, and it would be good to ask all those people why........ IS it because they don't WANT t o use it or because being told they shouldn't. Media influence. If tomorrow there is a big trend that wearing pink shirts and rainbow shoes is the next big thing, everyone will want to wear them.All of your post was totally off-topic. Because nothing I said was about a "trend", it was because Flash crashes every 15 minutes on some PC's (like mine), consumes GB's of ram (when using flash in youtube for example) and is slow as shit. Java wasn't popular for web in the first place (nothing more than a few applets here and there) and I don't see why it would become more common when browsers can do a lot of stuff natively now. Firefox has an, for now, unofficial extension for Microsoft Kinect for god's sake. If you can input real-time point clouds and do calculations on them using nothing more than JS, then really there is need for additional plugins like flash or java. Even camera (like webcam) interface is becoming standardized. Just like microfone input. So you can do equalizers and music visualizers in pure JS. And all of that runs (or can run) in real-time even on crappy PC's.
Quote
The article also uses a JavaScript benchmark that JavaScript engines have been optimized for (which is pointless because nobody actually runs benchmarks, they run apps, and the results are often very different), and that native has not been optimized for (because, again, that would be pointless).Well then another comparison is here: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/ It's not really compared to Java, but it is compared to native compilers which are usually faster than Java anyway. And it seems the gap is quite small. Especially considering how even clang and gcc vary between themselves. As that topic explains, the problem is that JS has only one datatype. That greatly reduces speed as the compiler cannot really optimize for types. But the same is true for ENIGMA, as usually people use only one data type as well. And our datatype is even slower, as it can be a real or a string, while in JS at least you can differentiate the two. So ENIGMA could actually be slower than freaking JS, but we are still "native".
Another cool demo (one of the first ones ever): https://developer.mozilla.org/en-US/demos/detail/bananabread
And a good read: https://hacks.mozilla.org/2013/12/monster-madness-creating-games-on-the-web-with-emscripten/
The only problems with HTML5/JS games is that you have to download them every time you want to play, as they usually are not stored on your PC/device. So loading times can take a long time for big projects. But there are mechanisms to store data so you don't have to redownload everything all the time.
675
Issues Help Desk / Re: Font rendering is broken again ! (updated)
« on: May 26, 2014, 06:47:19 am »
We could try that. But non-integer coordinates are sometimes useful for, like AA sometimes work better with floating point coordinates.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »