• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

sasho648

Members
  • Content count

    49
  • Joined

  • Last visited

Community Reputation

78 Neutral

About sasho648

  • Rank
    Member
  1. Well thank you for the remind. Now please can I say something? I think 'C++' has many flaws. One of them is the functions. Although I don't know nothing about 'C++' I don't like them.
  2. I know 'C++' as well as 'C' and I can't assure you the problems I've stated above are all still valid in 'C++'. And although optimization can take place for the return value - the things are not the same for the function parameters. I highly doubt that the compiler will optimize the code I have written above. Or maybe it'll who know? But in every case I find it a flaw that things which could be very easily handled by the programmers itself are left to the compiler which could or could not optimize certain thing. After all wasn't the power of 'C' that is closest to the low-level languages?And in certain cases even the compiler can't help. How could you return a VLA for example using the current syntax?In every case I found those things as a flaw. Because they add at-least a confusion (if not so performance issues).
  3. Some of syntax improvements went wrong I guess because I used '<' the first is when I meant that array operator '['']' shall apply only on array types and shall mean accessing the array element.The other thing was how to properly define a function, similar to variables. But I guess that is not so important.
  4. C++ is for horses. However the biggest flaw of it for me is where it comes from - 'C':'C' have one big flaw - functions.Although they look fancy and easy to use - the cost is waste of system memory and flexibility.This is because you can't actually use the 'function parameters' as what they're - named variables in the calling function. And also the returned value - in the function which must return.For some-time I though there was a big flaw with the implementation of arrays in 'C' - because you know you can't directly copy them, there is no array indexing operator (you now cry - there is '[]' - search google what this actually is and then come back again) and they can't be either returned nor passed as arguments to functions (again you say - how come you can't pass array to functions - however if you say this go read 'C' standard and then come back again).However recently I thought I'll try imitating what the 'C' creator was thinking when he created arrays. And I come to the conclusion that he made them as simple as possible by reusing already existing operation - the addition of pointers with integers. I think here it would have been better if he had added a new specific to arrays operator which could allow the compilers earlier diagnosis of accessing element out of bounds (and not a general one - which in practice is used only for arrays). However here I'm not exactly sure if the mistake was his or on the people who have standardized the language. Because even if he had meant '[]' to be a operand working with all kind of variables - the people creating the standard could simply see it's original meaning and usage and so create it an array specific one avoiding confusing code and allowing the diagnosis stated above. What I mean is code like this that is currently allowed:[source lang="c"]int arr[6];arr[6]; //ok although UB - can't be diagnosed (as the 'arr' is implicitly converted into //'int *' pointing to array first element and so the array-size information is lost) //same as *(arr + 6) 2[arr]; //ok not UB but kinda confusing huh? //same as *(2 + arr)[/source]If '[]' was an array special operator with syntax like this:[]The above code would not be allowed. The firs line will be diagnosed as not possible at compile-time (as the array have only 6 elements) and the second is a syntax error because '2' is not an array type.This is about accessing array elements. Now I'll move on to the other more general problem - why the 'C' creator didn't allow us to directly copy arrays? Why did he insisted that in expression they'll mostly 'decay' into pointers (unless used in a 'sizeof' expression for example as it is for now)? I can very easily come to this solution. It was because he was making a language that closely represents the machine low-level instructions (and also because he was lazy to make it more complex then this I guess?). In every case copying array would not be possible using a simple machine instruction at the time - the compiler should add a lot of code in order to achieve that (I guess?) because low-level machine assembly language was working with small-sized primitives (of 32bit) which was represented by 'ints', 'floats' and etc. in the current 'C'. You can now argue what about structure copying? Well as from what I've heard this feature was added later as an extension (the people which have added it weren't thinking much of what was the idea of 'C' but instead they've seen an easy way to make their work codding in 'c' easier I guess?). So anyway I can understand that. He meant arrays to be manually filled. I can't talk for array-initialization though - because if this was part of the first 'C' created then I've no idea why he decided to make arrays in the state they are now (because array-initialization involves automatic array filling/copying).So far so good in order to copy arrays we need to do that ourselves. We got our array declared - we got it's type and name. Now we can write a for loop... Wait what? You want to pass it as an argument to a function? But what we do now? Does arguments have names?Here is the big, big problem. We can only copy-initialize function parameters, as well as function return value. In this case we can't copy our arrays! And even if we could (suppose that arrays were copyable) - this limit us in a way that we can't directly modify the argument value. Suppose that we want to pass a structure to some function. However we can't simply copy-initialize it and we want for some reason to use a loop:[source lang="c"]typedef struct { int m1[20]; int m2;} someType;someType var;for(int i=0; i < sizeof(var.m1) / sizeof(var.m1[0]); ++i) var.m1 = i * 34; //consider some complex calcs instead for(int i=0; i < 34; ++i) var.m2 |= i * 34; //consider some complex calcs instead (maybe hash calculation?)void func(const someType *); //our function where we pass our structure //to be read of-coursefunc(&var); //pass a pointer to our structure we have just complexly initialized[/source]Here we have wasted the memory of one pointer, additional copying and reading from tOf-course we could also use a global-variable but you can then ask what is the stack for? Imagine we are calling this function from multiple threads? Or we are calling it in a recursion. Or we simply don't want to waste memory when the function is not called.Now you wonder - how could we make this better. I tell you on the moment. If we instead get closer to the low-level machine language as 'C' was intended to do - we must note that actually those arguments (in almost all implementations) are stored on the stack from the calling function as normal variables and then the called function simply access them as if they were declared in it (which they are in-fact). There is simply an agreement how many, in which order and what type the argument variables are stored in the stack so the caller, and called function could communicate. If we name those variables and allow accessing them as other normal variables (instead of only allowing copy-initialization)- we could have more option to storing data into them. Like in this example using loops. This way we have saved ourselves the drawbacks stated in the last paragraph. The same could apply for return values. We are talking about named access to the variables that pass and return from a function. Here is what this would looks like in practice:[source lang="c"]{typedef struct { int m1[20]; int m2;} someType;void func(someType); //our function where we pass our structure //it'll take out a single 'someType' variable from the stacksomeType var; for(int i=0; i < sizeof(var.m1) / sizeof(var.m1[0]); ++i) var.m1 = i * 34; //consider some complex calcs instead for(int i=0; i < 34; ++i) var.m2 |= i * 34; //consider some complex calcs instead (maybe hash calculation?)func(); //here the 'func' have direct read-write access to our lastly declared variable //which must be from type 'someType' - ak. 'var'} //brackets so the argument variable life-time ends just as when the function returns[/source]For return-variable named access I suggest storage-specifier 'return' which will define the returned variable in function scope.Example:[source lang="c"]someType ReturnOurStruct(){return someType var; //we can now directly access our return-valuefor(int i=0; i < sizeof(var.m1) / sizeof(var.m1[0]); ++i) var.m1 = i * 34; //consider some complex calcs instead for(int i=0; i < 34; ++i) var.m2 |= i * 34; //consider some complex calcs instead (maybe hash calculation?)}[/source]That put aside I think that function lack another proper thing - syntax. The fact that you can store parameters names in a type is somehow not in place. Also the fact that you can't define functions using typedefs and local ones. I got a solution for this too. Firstly funcion types can't specify parameter names and secondly we will define a new syntax for defining functions like ordinary variables: = { , } { }Another thing that I don't like are statements, declarations and other stuff but if I continue I'll simply define the whole new language I think 'C' must become. However the recent general - performance eating problem (which is not either syntax sugar or compiler checking for drunk programmers) was the one I talked about - functions.
  5. And also in a matter of fact - VLAs are very useful as you have already pointed out when there you've used only a single such variable. Because in such cases they are created faster then calling for example 'malloc'. Another thing is as you probably know newer 64bit processors have a lot more registers then 32bit ones so I'm sure that even using more then a single VLA can be optimized and work faster then 'heap'.
  6. I already know how VLAs are represented. And I still like them. It's my own personal opinion. However my problem is that I can't find any good-languages (besides C/C++ and the ones listed on the Wiki-Page describing what VLA is) that supports them (I mean proper by default support, without for example the need of calling a function like 'alloca').
  7. And besides 'C++' too. I already knew that one.
  8. I mean what programming languages out there support C-like VLAs (which are stored on the stack rather than the heap), other than C itself? As you probably don't know VLA stand for a variable-length-array which is defined in 'C' in a way that most compilers will store them onto the 'stack' (instead of how most modern languages instead use the 'heap'). In case you do however I'll be glad if you help me to find non-100 years old, legacy carrying languages that meet this requirement.
  9. HI!   Thanks for sharing, this is more useful than the version I already had (from 2000) but this is actually 2002. I need the version from March 2003. But anyway again thanks for the help because this version is the closest to what I need  .
  10. Does sombody have this SDK? (It's called also DirectX 9.0a) If does I'll be grateful if he\she share it with me!
  11. Thank you but I already have it (from one chinese site) and actually there're some mistmatches with the SDK used and this one. I'll show what actually I need defined: [CODE] class SYS_DI_ADAPTER { public: SYS_DI_ADAPTER(DIDEVICEINSTANCEA const &, SYS_DI *, SYS_ERROR &); ~SYS_DI_ADAPTER(); SYS_ERROR GetSettings(SYS_DI_DEVICE_SETTINGS &); SYS_ERROR SetSettings(SYS_DI_DEVICE_SETTINGS &); SYS_DI_ADAPTER_OBJECT * FindObject(unsigned long, unsigned long)const; private: SYS_ERROR RegOpenKeyA(bool,HKEY &); SYS_ERROR SetSettings_Registry(SYS_DI_DEVICE_SETTINGS &); SYS_ERROR GetSettings_Registry(SYS_DI_DEVICE_SETTINGS &); SYS_ERROR GetSettings_Default(SYS_DI_DEVICE_SETTINGS &); SYS_ERROR GetAdapterInfo(SYS_DI *); static int __stdcall DIEnumDeviceObjectsCallback(DIDEVICEOBJECTINSTANCEA const *,void *); static int __stdcall DIEnumDeviceEffectsCallback(DIEFFECTINFOA const *, void *); public: DIDEVICEINSTANCEA m_0; //size 580 SYS_DI_ADAPTER_OBJECT* m_580; //size 4 DIDEVCAPS m_588; //size 44 SYS_DI_ADAPTER* m_632; //size 4 } ; //size of 636 class SYS_DI { public: SYS_DI(SYS_COMMAND_LINE const &,HWND,SYS_ERROR &); SYS_ERROR Create(); void ClearPS2PAD(); void CloseDevices(); SYS_ERROR Setup_Playback(char *); SYS_ERROR Setup_Recording(char *); BOOL LoadControl(CONTROLLER_TAG &); SYS_ERROR CreateDI(); SYS_ERROR EnumDevices(); static int __stdcall DIEnumDevicesCallback(DIDEVICEINSTANCEA const *, void *); SYS_COMMAND_LINE const & m_0; //size 4 HWND m_4; //size 4 BYTE m_8; BYTE m_9; HMODULE m_12; //size 4 HRESULT (*m_16)( HINSTANCE hinst, DWORD dwVersion, REFIID riidltf, LPVOID * ppvOut, LPUNKNOWN punkOuter ); //size 4 LPDIRECTINPUT8A m_20; //size 4 unsigned char m_256; unsigned char m_257; HANDLE m_260; //size 4 HANDLE m_264; //size 4 SYS_DI_ADAPTER* m_268; } ; SYS_ERROR SYS_DI_ADAPTER::GetAdapterInfo(SYS_DI * a0) { SYS_ERROR result = SYS_ERROR_UNKNOWN; __try { LPDIRECTINPUTDEVICE8A v0 = 0; if(a0->m_20->CreateDevice(m_4, &v0, 0)>=0) { DIDATAFORMAT tDat; tDat./*m_24*/ = 24; //offset HERE!!!!!!!!!!!!!!!! tDat.dwSize = sizeof(DIDATAFORMAT); tDat.dwObjSize = sizeof(DIOBJECTDATAFORMAT); tDat.dwFlags = 0; tDat.dwDataSize = 0; tDat.dwNumObjs = 0; tDat.rgodf = NULL; if(v0->SetDataFormat(&tDat)>=0) { if(v0->SetCooperativeLevel(a0->m_4, DISCL_EXCLUSIVE | DISCL_FOREGROUND)>=0) { memset(&m_588, 0, sizeof(DIDEVCAPS)); m_147 = sizeof(DIDEVCAPS); if(v0->GetCapabilities(&m_588)>=0) { if(v0->EnumObjects(&DIEnumDeviceObjectsCallback, this, DIDFT_ALL)>=0) { sysDXListReverse(m_580); if(v0->EnumEffects(&DIEnumDeviceEffectsCallback, this, DIDFT_ALL)>=0) result = SYS_ERROR_NO; } } } } } RELEASE(&v0); } __except(1){} return result; } [/CODE] So what is this the DIDATAFORMAT structure is with 24 bytes size but the program code is trying to access the element in it at 24 offset (this mean there need to be one extra member). Is this defined only in DirectX 9.0a but not in DirectX 9.0? And the other strange thing is this http://www.gamedev.net/topic/634619-enum-d3dformat-problem/. Where is these format defined? Actually there isn't such an enumeration member in DirectX 9.0. The program ReadMe file says that it was used DirectX 9.0a. So that's way I think this is my problem.
  12. Why you think I have colleagues? [img]http://public.gamedev.net//public/style_emoticons/default/rolleyes.gif[/img] Anyway if somebody have this SDK I'll be glad if he/she upload it and send me the link.
  13. No this is not my problem. I'm reverse engenering program which was compiled with this SDK so that's way I need it. [quote]You would search the SDK through the Internet or ask someone only.[/quote] Hwo to ask ? Any ideas ?
  14. Excuse me but wtf? What is this doing with DirectX 9.0a?
  15. No I need exactly DirectX 9.0a SDK from 2003. Not the new one. Please help!