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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »
781
Programming Help / Re: [Solved] Adding a new function
« on: October 04, 2014, 07:12:40 pm »Quote from: lonewolf
the error checking would return a D3DERR* message, not simply crash the app.No it would not, because the FAILED() macro does not check for garbage pointers, it doesn't check for pointers at all in fact.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms693474%28v=vs.85%29.aspx
Code: (cpp) [Select]
#define FAILED(hr) (((HRESULT)(hr)) < 0)
The following would crash.
Code: (cpp) [Select]
if(FAILED(d3dDevice->CreateVertexBuffer((nNumVerts)*sizeof(D3DVERTEX),D3DUSAGE_DYNAMIC|D3DUSAGE_WRITEONLY,D3DFVF_XYZRHW|D3DFVF_DIFFUSE,D3DPOOL_DEFAULT,&pVertexObjectQuad,NULL)));
Even if you took it out of the macro, before it even enters the function, that's GCC/MinGW/C++ not DirectX failing.
Code: (cpp) [Select]
d3dDevice->CreateVertexBuffer((nNumVerts)*sizeof(D3DVERTEX),D3DUSAGE_DYNAMIC|D3DUSAGE_WRITEONLY,D3DFVF_XYZRHW|D3DFVF_DIFFUSE,D3DPOOL_DEFAULT,&pVertexObjectQuad,NULL);
782
Programming Help / Re: C++ DestroyWindow() alternative
« on: October 04, 2014, 02:30:42 pm »
This post suggest you can set the parent of it to NULL and then destroy it.
https://forums.ni.com/t5/LabVIEW/Remove-Child-Window-from-Parent-using-WIN-API/td-p/1470888
https://forums.ni.com/t5/LabVIEW/Remove-Child-Window-from-Parent-using-WIN-API/td-p/1470888
784
Issues Help Desk / Re: Bad C++ generation
« on: October 04, 2014, 09:28:48 am »
Sorlok, I'll be honest, I was more interested in overloading var for array so we can test array lengths and also to return arrays of pixel data from background functions, like background_getpixels is what I wanted to do. Studio added some of these functions which I'd also like to have. It is much easier for heightmaps and stuff, and the old way of drawing to the screen then draw_getpixel one at a time was soooooooo slow. But currently regular arrays don't even work in the parser, and to overload var we'd also have to overload std::array which I tried and failed at.
785
Proposals / Re: Extended Binary
« on: October 04, 2014, 09:02:20 am »
Howdy, and welcome to the forums!
Quote from: TheStolenBattenberg
But I'd like to ask, is modifying the source directly preferred to creating an Enigma extension?It depends really, we try to keep a solid and stable base of functions from GM, but just about everything that some particular user would not directly need we try to throw into an extension. Simple rule of thumb is that if not everybody needs it; put it into an extension.
Quote from: TheStolenBattenberg
I guess if extensions are preferred, they'd be a template for adding them?Yes sir, there is, just follow the other extensions in engima-dev/ENIGMASystem/SHELL/Universal_System/Extensions
786
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 08:53:17 am »Quote from: Harri
That is weird. Can you run in Debug mode and see if it outputs anything to console?I believe it might be because that game uses screen_refresh() to read the heightmap data from the background/sprite. Sorlok, are you testing on Compiz?
Quote from: Harri
Performance gain is basically because of reduced GL function calls, in Project Mario they went from 5215 per frame, to 3222. Almost 40% reduction. But sadly it doesn't mean much, as some calls are very fast, others are not. Optimizing for the slow ones is the way to go from now.
I can tell you, I think some of the slow down is VBO's used for sprite/background batching. I believe vertex arrays are a lot faster for dynamic draw. But this is in regards to regular consumer hardware, I don't have a graphics card as good as yours Harri, so in some cases (like sprite batching) software vertex processing is just optimized a lot more I guess.
787
Programming Help / Re: Windows 8 touch support
« on: October 04, 2014, 02:20:55 am »
Well I've got bad news, I started trying to write the extension and found out WM_TOUCH does not work with MinGW, the winuser header is all screwed up.
http://sourceforge.net/p/mingw/bugs/2236/
Ticket was just updated around the time we started discussing this. I am not sure what to do at this point.
X touch support looks pretty straight forward on the other hand.
http://who-t.blogspot.com/2011/12/multitouch-in-x-getting-events.html
I have gone ahead and outlined the Win32 extension in my pull request anyway; I believe I can just format the winuser header if I find it in the Windows SDK and redistribute it like I did for Direct3D11
https://github.com/enigma-dev/enigma-dev/pull/842
http://sourceforge.net/p/mingw/bugs/2236/
Ticket was just updated around the time we started discussing this. I am not sure what to do at this point.
X touch support looks pretty straight forward on the other hand.
http://who-t.blogspot.com/2011/12/multitouch-in-x-getting-events.html
I have gone ahead and outlined the Win32 extension in my pull request anyway; I believe I can just format the winuser header if I find it in the Windows SDK and redistribute it like I did for Direct3D11
https://github.com/enigma-dev/enigma-dev/pull/842
788
General ENIGMA / Re: ENIGMA's Engine Code - License Comparison
« on: October 04, 2014, 02:18:42 am »
Right I understand Rez, and I agree. Now, don't everybody freak out, but what about Creative Commons? I know I know, but still it is a choice.
789
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 12:06:09 am »
Sorlok, as far as the shader output, it would probably be better to post enigma-dev/output_log.txt because I believe we throw the errors in that file.
790
General ENIGMA / Re: Lateral GM question
« on: October 04, 2014, 12:04:54 am »
Alrighty, but yeah lots of bug fixes have been made, and I can't fix things without knowing about them... so how else will they ever get fixed? etc etc
791
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 11:43:27 pm »Quote from: Darkstar2
and you said the problem is with enigma.jar (the plugin) and not the IDE itself, these problems start to happen eventually - the longer I work in LGM,Right exactly, that's the plugin, ENIGMA, not LateralGM. I only notice it when editing ENIGMA source engine files though, not just having LGM open or compiling multiple times, if I don't change source files I have no issues. Also I only seem to have a crash when mainly working with templates or STL because of how big the error logs are and it gets worse over time before crashing. That's an issue I'd like to work out.
Quote from: Darkstar2
Some are so easy to reproduce, just frequently save your project, eventually it will error out and the entire MFing project gets corrupted., including backups.I literally saved Project Chaos over and over and over and over about a hundred times, and the JVM never tops 305mb RAM usage, just stays between 299 and 305.
792
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:30:39 pm »
Oh boy sorlok, I haven't really worked with dll's that much so I don't know how to reproduce and test what he's testing. In fact I don't think I've ever written a dll before, except changes to the compiler which make compileEGMf, but other than that I've never made my own dll's before. Additionally Josh would be the best person to talk about variant, I don't think I would be able to fully understand the implications.
793
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:07:46 pm »
Ok my apologies sorlok, I have run some tests and it appears your code is working fine.
WINDOWSmain.h
graphics_bridge.cpp
Object Draw Event
Works perfectly as expected and clears the background color to red. It must be an issue with the dll functions then.
WINDOWSmain.h
Code: (cpp) [Select]
namespace enigma_user
{
void test_draw_clear(void* d3ddev);
void* window_device();
unsigned long long window_handle();
int sleep(int millis);
}
graphics_bridge.cpp
Code: (cpp) [Select]
void* window_device() {
return (void*)d3dmgr->device;
}
void test_draw_clear(void* d3ddev) {
IDirect3DDevice9* dev = (IDirect3DDevice9*)d3ddev;
dev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_RGBA(255, 0, 0, 255), 0, 0);
}
Object Draw Event
Code: (EDL) [Select]
test_draw_clear(window_device());
Works perfectly as expected and clears the background color to red. It must be an issue with the dll functions then.
794
Developing ENIGMA / Re: Unstable master?
« on: October 03, 2014, 10:53:24 pm »
No actually, it would increase performance for games that scale up because currently we resize the backbuffer and the game gets rendered at a higher resolution. GM always keeps application_surface the same size as the region and then scales it, so when you set the game fullscreen the resolution doesn't increase it just scales, ENIGMA does increase the resolution.
795
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 10:51:13 pm »
IsmAvatar, the first whole part of your post I think we understood just fine, nobody is advocating for getting rid of the callbacks, no way at all.
But basically the reason we haven't done this yet is because I've wanted to make LGM very very stable with some awesome features, such as the search tree, before any GMK support is dropped. LGM in its current state is basically becoming better than GM8.1 or GM ever was as an IDE pretty much.
Quote from: ismAvatar
@TheExDeus: While it's true that writing only the changes to the file could be faster than sending the whole file in memory, we need to remember a few things:Here's where you seem to be kind of confused about our proposal though, that even Josh wants. If the project exists on disk, you don't have to load anything, the user clicks a resource and it is loaded and then they can change it in the editor, when you hit the save button all changed resources are committed to disk, and we would require you to save before changes would be reflected at runtime. This is like many other IDE's, but it would make LGM much better at working with large project files, even a native IDE should not have resources loaded that it is not concurrently working with or the user has any interest in. Does that make sense? But these changes would mean abandoning the GMK format because it is not easily expandable for this functionality, but EGM being ZIP's and GMX's being zip friendly those formats can do it.
* In LGM, the file is already in memory. Sending that memory to ENIGMA does not require any effort, because it's shared memory. It's just a library function call to tell ENIGMA to actually read that memory.
* While having LGM save the file would be faster that way, you completely forgot that ENIGMA (cli) would now need to load the whole file. With library calls, the whole file is already in memory.
* The main reason for the slowdown in communicating the file to ENIGMA is because of a few limitations we had to deal with at the time which we continue to streamline. Mainly, we decided to rewrite the entire file into new slots of memory for passing to ENIGMA. That's completely unnecessary. If we just wrote the changes to memory and marked those as changes (so ENIGMA knew that those are the only parts that changed), that would be a better comparison to the individual resources written to file - and it would necessarily be faster because memory is always faster than files.
But basically the reason we haven't done this yet is because I've wanted to make LGM very very stable with some awesome features, such as the search tree, before any GMK support is dropped. LGM in its current state is basically becoming better than GM8.1 or GM ever was as an IDE pretty much.
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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »