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 »
1531
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 28, 2012, 07:05:43 pm »
But it still supports everything. The speed is not the issue, its the specification. That one supports DX11 as well as GL 4.2, while mine 8800 supports DX10 with only GL 2.1. So if I can use FBO's, then she certainly can (and almost anyone can, so I don't get why Josh had his panties in his ass when I told him I want GLEW and FBO's for surfaces). For now it seems that maybe the previous results when some who tried had errors about extensions not supported, in really had the support and only the code was flawed. I am interested to see if the fixed .cpp fixes it.
1532
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 28, 2012, 05:47:35 am »Quote
Actually, there IS an error. In the terminal: "Adding background: 1Extension NOT supported!!"This error is no longer shown. It just shows if GLEW is loaded or not, and if it is, then you can check support with the is_supported function.
Ok, so there was a little fuck up. The part where glew is initialized is this:
Quote
#ifdef _WIN32So this meant that only windows had them. Its weird that it can run without errors (just return 0's I guess) even without init. Although I can't remember if this #ifdef was because of necessity (glew support) or just because I can't test nothing on linux.
GLenum err = glewInit();
if (GLEW_OK != err)
{
std::cout<<"GLEW ERROR!"<<std::endl;
}
std::cout<<"GLEW LOADED!"<<std::endl;
#endif
Try downloading this file: http://dl.dropbox.com/u/21117924/Surfaces/OPENGLStd.cpp
and putting it in: \ENIGMAsystem\SHELL\Graphics_Systems\OpenGL
Then you might get some GLEW errors but I don't know.
And yes, 430 should support FBO's just fine. Only VERY old cards and some kind of old laptop cards don't support them. I have Geforce 8800 which is about 5-6 years old (and now costs pennies) and I can support them just fine. I have a laptop with some ATI mobile radeon and it can support them as well.
edit: -DarkAceZ- could also test this. Maybe this is why he had the extension not supported error before (that is if he runs linux). Easier would be to run on windows and just try to launch the already compiled exe's I gave. Then see if they run fine. Maybe even trough Wine it could work (Josh uses it all the time with ENIGMA).
1533
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 27, 2012, 05:39:07 pm »
Yeah, then you sadly don't support FBO's. Can anyone else test with a different GPU?
Also, the surface_is_supported() function was made just for this reason. So it wouldn't crash unexpectedly or just show a black screen. I could just check for support and fallback gently. I didn't do it in the examples though.
What GPU do you have? I guess its a laptop?
Also, the surface_is_supported() function was made just for this reason. So it wouldn't crash unexpectedly or just show a black screen. I could just check for support and fallback gently. I didn't do it in the examples though.
What GPU do you have? I guess its a laptop?
1534
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 27, 2012, 03:51:34 pm »
Thats weird. Does your PC support FBO's? The function surface_is_supported() should return true.
The syntax error is because for some unknown reason linux and/or mac's have "time" as a function. On windows you can use it as a variable just fine (it doesn't highlight as a function either). Download it again. I just renamed the variable.
Also, I don't know if the GIT version works at all, as I can't run it on Win. Until people fix that, I will not be able to really fix problems like these.
The syntax error is because for some unknown reason linux and/or mac's have "time" as a function. On windows you can use it as a variable just fine (it doesn't highlight as a function either). Download it again. I just renamed the variable.
Also, I don't know if the GIT version works at all, as I can't run it on Win. Until people fix that, I will not be able to really fix problems like these.
1535
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 27, 2012, 12:41:15 pm »
Yes.
1536
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 26, 2012, 05:02:49 pm »
Success!
Now if people can run the git version (so Linux and I guess Mac) could try to compile these:
http://dl.dropbox.com/u/21117924/Surfaces/development_side_effect2.gmk
http://dl.dropbox.com/u/21117924/Surfaces/reflections_surface.gmk
http://dl.dropbox.com/u/21117924/Surfaces/sun_rays_room_technique%20V2.gmk
edit: Why is sirmxe spamming git?
Now if people can run the git version (so Linux and I guess Mac) could try to compile these:
http://dl.dropbox.com/u/21117924/Surfaces/development_side_effect2.gmk
http://dl.dropbox.com/u/21117924/Surfaces/reflections_surface.gmk
http://dl.dropbox.com/u/21117924/Surfaces/sun_rays_room_technique%20V2.gmk
edit: Why is sirmxe spamming git?
1537
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: March 26, 2012, 01:09:24 pm »
Ok so I have problems with this GIT thing. Tried about 2 hours to commit some changes and this stuff is just idiotically complicated. I see no reason why version control needs more than 3 buttons (or at least visible ones). I think I did commit something, but it commit locally? Now when I try to commit to "master", then I have problems with authentication. This is the error:
Quote
C:\ENIGMA_Git\enigma-dev>git pushWhere do I need to add this public key? And where is it in GitHub? Is it the "API token"? That seems like the only thing that deals with password and the like.
The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of know
n hosts.
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
1538
Announcements / Re: New members
« on: March 25, 2012, 06:56:32 am »
Windows has some path problems poly and cheese managed to kind of fix (with a 600mb zip). Maybe someone could look into that. I still want to update some of the functions and as I have the privilege now to do so, I will try that. Although first time gitting could end up a disaster.
1539
Announcements / Re: New members
« on: March 23, 2012, 04:37:36 pm »
Yeah, the name of the "Forum" seems a bad structured question. A better would be the name of the "project", which clearly is ENIGMA. Or just type "Read the banner and write it backwards" which seems like a big task for a bot.
1541
Proposals / Re: New ENIGMA Implementers' API; this concerns all developers
« on: March 21, 2012, 11:54:41 am »
You mean that debug mode will show an error in that case (because it doesn't now)?
1542
Proposals / Re: New ENIGMA Implementers' API; this concerns all developers
« on: March 21, 2012, 08:08:36 am »
And what about undefined variables? I hate that ENIGMA just takes 0 or something when a variable is not defined - it creates A LOT of headaches (just a few days ago I wasted 3h figuring out why ds_ functions don't work properly, in reality I didn't create the ds_ in the first place, but I can't know that if it takes 0 by default).
1543
Proposals / Re: News points
« on: March 20, 2012, 07:33:48 am »
I hope you took into consideration varargs in the parser, so we don't have problems with them. Like the two problems we have now:
1) min/max always defaults to varargs even when only two arguments are given (this is slow).
2) varargs fuck up variable name access, so we get a compile error (like max(5,global.somevar) will fuck up the global.somevar).
Also, its cool that the parser does trivial mathematical operations. I usually do draw_sprite(x+10,y+10+64) and such when drawing and positioning items, so its cool that it will just return 74 and doesn't do that calculation all the time during runtime (although doesn't gcc already do this?). And does shit like this break it: x+5*(4/somevar)*64, so will it return x+320*(4/somevar)?
1) min/max always defaults to varargs even when only two arguments are given (this is slow).
2) varargs fuck up variable name access, so we get a compile error (like max(5,global.somevar) will fuck up the global.somevar).
Also, its cool that the parser does trivial mathematical operations. I usually do draw_sprite(x+10,y+10+64) and such when drawing and positioning items, so its cool that it will just return 74 and doesn't do that calculation all the time during runtime (although doesn't gcc already do this?). And does shit like this break it: x+5*(4/somevar)*64, so will it return x+320*(4/somevar)?
1544
Proposals / Re: New ENIGMA Implementers' API; this concerns all developers
« on: March 16, 2012, 11:25:15 am »
That's cool.
edit: And there is no overhead because that is done on compile time?
edit2: Is it faster is what I am asking..
edit: And there is no overhead because that is done on compile time?
edit2: Is it faster is what I am asking..
1545
Proposals / Re: New ENIGMA Implementers' API; this concerns all developers
« on: March 16, 2012, 07:10:02 am »
So instance_destroy() would look like this?:
But this doesn't concern me I guess. I don't make these kinds of functions, but this seems important when I get around doing path_start (as no one else plans to).
Code: [Select]
void instance_destroy(enigma::object_basic* _E_SELF)
{
if (enigma::cleanups.find(a) == enigma::cleanups.end()) {
_E_SELF->inst->myevent_destroy();
_E_SELF->inst->unlink();
}
}
I guess the function wouldn't error with "not enough arguments" when called empty (like usual) because of the parser?But this doesn't concern me I guess. I don't make these kinds of functions, but this seems important when I get around doing path_start (as no one else plans 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 »