• 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.

JohnnyCode

Members
  • Content count

    1628
  • Joined

  • Last visited

Community Reputation

1046 Excellent

About JohnnyCode

  • Rank
    Contributor
  1. You realy got stuck on something, and I have said it multiple times as well: You say that using & operator is not using a reference, that only using the referenced object (cpp dereference), by a reference variable (that is lvalue of & type)- is using a reference. Then you support this statement by my mistaken knowledge of references in cpp I had. It went too off topic, and I will not respond to that issue anymore.
  2. I have explained it, operator & is used, thus a reference is used. It did have references, but in your defintion that I observe from here, didn't. Realize you are doing an exclusion from the definition, while I was doing my own mistaken exclusion from defintion too of course. C had & operator that provided addresses of instances, for example for managing of pointers, not the memory they point to. But did not have a reference in extended way of it being an l-value typed variable. We can stop this discussion, I just insist that by using & operator you have used a reference (though yet did not use referenced memory yet).
  3. I know, I did. My meaning is that reference, wheather l-value, or r-value, is still a reference? And I say you use it when you actualy invoke it. I's aware of misunderstanding them already away, I hadn't continued my speach in that pattern anymore.     You have used a reference, to establish a pointer from it.     In C language for example, references could not be l-values, in C++ they could, that is perhaps where I picked it from. And as I mentioned, introducing heap allocation guarantee break by making type& lval possible in C++ (in a more hidden obscure ways I mean). I personaly am interested why is WiredCat solving the inline function like that, by manipulating index in the reading function, doing stack-crossing.
  4. The second method, though seems to have redundant code (since you seem to unpack a cycle? dunno), is not introducing cache incoherency, just to do something as trivial as an index change, at ideal best, the inline function of first method would reach nearly-the same cache coherency as the second method (maybe). You still can use sane overloads to retrieve indexed infromation, yet I cannot read why since you know count and index and type up front the call? You have used a reference.
  5. I haven't used references for myself. I have worked in Visual C++ 6.0 professionaly, and I didn't encounter references on the scope of entire project code base. I think references quite break memory security, since you can introduce them to (type*) parameters of functions, while they can be addresses of local/temporary variables, breaking heap allocation guarantees. WiredCat could have done this inline int read_int_from_stream(int count, int index, char * src) { return *((int*)(src+index*4)) }
  6. Yes, I know, this is how I expected it to work, and I must admit, that I have used it in that way long ago?
  7. In my knowledge this'd have been equivalent to that code: int x = 1; int& y = x; // snatches addreess of x into actual int* y *y += 1; // does NOT increment the address std::cout << *y; *y = 5; // does NOT set the address to 5 printf("%i", *y); I havent used references for so long. I am still not sure for pre-11 standard??? Since, for example: int* a; int** ap=&a; **ap - provides *a
  8. So this code hang on me for the very link link, I alter only compilation standard to first one. #include <iostream> class SomeType{ public: SomeType(){} int a; int b; int c; }; void myFirstFunction(SomeType &value) { std::cout << value << std::endl; } void mySecondFunction(SomeType *value) { std::cout << value << std::endl; } int main() { SomeType myInt(); myFirstFunction(myInt); mySecondFunction(&myInt); }
  9. In my knowledge, if a parameter is declared as Type &vari , and recieves an instance of Type on itself, it will provide sole address of that variable. Either- it is not actual anymore, or, it hasn't been true about basic integrated types of the language? I have gonne to the web-page, and for the 98 standard, the one before C++11, compilation hangs on work, if I apply a custom type instead of int type to the inspected variable. Your observation about a need to reference & before the passed variable could not apply to not-value passed instances to parameters, I am still investigating this issue.   Very inccorrect generalization, you must admit that's actualy omitting a reference existance?
  10. I know the difference, it sounds you seem to not pick it up from me, I'll try to phrase it in a more definitive way then: -Reference provides adress of a variable/ a pointer to the memory of the variable. -Pointer is a whole unsigned integer number, that is an address in memory, can be of 4 or 8 bytes large. int value=1; myFirstFunction(value);/*Console is written some whole number that points to the momory where 4 bytes on "value are"*/ myFirstFunction(1); /* Console is written some whole number that points to the memory where 4 bytes of a stacked local param is */ mySecondFunction(&value); /*Console is written some whole number that points to the memory where 4 bytes on "value are"*/ int main() { int myInt = 7; myFirstFunction(myInt); // as I said, address of myInt mySecondFunction(&myInt);// as I siad, same number }
  11. it is actually NOT read from only as evident by the index = index + count line of the code   You are right on this one, but both, count and index, are number values that exist on the parameter scope- out of the function, so it is at least strange for someone to pass an int (the index)- and, without knowing it, earn it altered.   This gets a pointer to a specific location within the src buffer.  What is wrong with that?  He could have just did char* psrc = src + index, but either way same thing and I see nothing wrong with it.    No, it uses address of a 32bit/64bit pointer, then adds index to it, what is an address of some int   He is not copying from "some random space in memory".  It is from the space he specifically calculated as being in the src buffer passed in.  It is somewhat "arbitrary" the number of bytes as it is a passed in parameter.  That would be better to use sizeof(int) if he is indeed reading it into an int.  And yes he is reading it into a local variable....but he is returning that value at the end.  What is wrong with that?   No, he specificaly calculated a random point in memory literaly, becouse of what I mentioned upper, and if count is a bigger number, code will attempt to put more bytes to int dst variable.   index is an int.  count is an int.  how is that a memory reference adding to an integer?  he is using index to guess what, index in his array!!!  How else would you index other locations in an array or buffer without adding to the index?   index is a reference, an address to memory where the passed parameter is, count is an int, all integer numbers, thus can be added.   pot. kettle. black.    You should, or deal with uncorrectable memory leaks.
  12. inline int read_int_from_stream(int count, int & index, char * src) you use index variable of int type as a parameter to be only red from, yet you pass it as a reference, mind blowing { char * psrc = &src[index]; you have a pointer char* src to bytes, but you use address of this pointer, and use index variable reference for indexing ! int dst; memcpy(&dst, psrc, (size_t)count); you copy from some random space in memory arbitrary size of bytes into a local variable of int type! index = index + count; you add to a memory reference an integer psrc = 0; return dst; }   So, you realy need to learn something about memory unmanaged languages and approach them much more carefully.
  13. I am writting in this separate post, that you should stop making code in C++, at least temporarily, to stress it out. For your own wellness and security. Unless this code you posted is for a very educational purpose of your own. Now to your mad code...
  14. Sounds a lot like Silver, from Infogrames.