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

Archived

This topic is now archived and is closed to further replies.

Vlion

Why lisp?

104 posts in this topic

quote:
Original post by Nekhmet

This is the right notation for the job. My error rate has dropped to almost zero - when it was almost impossible to get things right before. I can add new rendering modes effortlessly.

To make it happen, though, I had to write a whole fricking compiler.


Why did you need to do all this for something that most people would just wrap in a function? Do you really need to be able to change all this outside the program?

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
0

Share this post


Link to post
Share on other sites
You mean write a function for each rendering mode? There would be the same possibility of error - when writing the function, I could forget to disable the stencil buffer, for example. It would be equally error-prone.

- Josh



[edited by - Nekhmet on February 29, 2004 12:01:59 PM]
0

Share this post


Link to post
Share on other sites
Maybe I''m missing something here, but it sounds really simple to me. You write one function that sets everything to your defaults, and call it before you set your mode specific values. This is basic programming.

resetState();
enableLighting();
enableStencil();
etc...

How is that more error prone than creating a ''little language''?
0

Share this post


Link to post
Share on other sites
The resetState method is a little more complex than you think, given the constraints:

* guaranteed determinism required (everything in default state unless I specifically mention it)
* minimize number of state toggles
* one I didn''t mention: vertex programs and fragment programs must be compiled in advance, I''m assuming that compiling a VP isn''t that fast.

For example, let''s say that "resetState" says this about lighting:

glDisable(GL_LIGHTING);

And let''s say I do this:

resetState();
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);

At this point, the code *appears* to have enabled one light. But, it contains a bug: at this point, several lights could be enabled, because resetState never disabled light1-light31.

So I could change resetState to look like this:

glDisable(GL_LIGHTING);
for (int i=0; i<31; i++) glDisable(GL_LIGHT0+i);

But now I''m doing 32 unnecessary state-setting operations in a very common case, namely, when lighting is off. I could minimize the state-setting as follows. First, keep one set of global variables indicating OpenGL''s current state. Second, keep a parallel set of global variables indicating what I desire it to be. Write an "applyState" function that compares the desired state to the actual state, and surgically fixes the actual state. Given this function, rendering would look like this:

resetState(desiredState);
desiredState.Lighting = true;
desiredState.Light[0] = true;
applyState(desiredState);

We probably want to move some of this code to initialization time. Vertex programs can''t be compiled at render time, this has to be done at initialization time. Second, these state-structs are gigantic, so it''s probably faster to set them up at initialization time. Let me alter the code:

initialization code:

// "resetState" is faster if called at initialization time:
// "compileVertexProgram" cannot be done at rendering time:
resetState(renderingState1);
renderingState1.Lighting = true;
renderingState1.Light[0] = true;
renderingState1.FragmentProgram = compileFragmentProgram("....");

at render time:

// Don''t know camera position at initialization time:
// Don''t know the texture at initialization time:
renderingState1.ModelView = currentCameraPosition;
renderingState1.Texture[0] = currentTexture;
applyState(renderingState1);
glDrawElements...

Unfortunately, now I''m back to where I started: I have a global state, which I''m modifying incrementally. I''ve lost my guarantee of determinism. I can fix this too, by copying the rendering state into a local variable and then modifying it locally:

{
RenderingState renderingState1a(renderingState1);
renderingState1a.ModelView = currentCameraPosition;
renderingState1a.Texture[0] = currentTexture;
applyState(renderingState1a);
glDrawElements...
}

Ideally, I should make the global rendering states "const" so that I can''t accidentally alter them, which would be a likely occurrence, given that I''m typing "renderingState1a.x=y" over and over. A one-character brain-fart would alter the global variable.

This solution is clearly sensible - a viable option. Which solution is better?

Well, given C++, obviously, this solution is better. It''s easy to program this solution in C++, hard to program the little-language solution. In fact, I''d say, I spent way too much time programming the little-language solution, if I had it all to do over again, I''d do it this way.

Which is better if you''re using Lisp? In Lisp, both solutions are equally easy to program, so the decision wouldn''t be made on the basis of programmer time. Instead, you would choose based on which notation you think is more elegant and expressive. I suppose that''s in the eye of the beholder.

To me, the point of it is that Lisp allows me to use little-language solutions. If you''re a Lisp programmer, you soon find yourself using little languages quite a lot. Even people in the C++ world use little languages occasionally - witness Corba, SQL, etc. But they don''t use them often, because of the high barrier to entry. Are they really an "important" tool? If you ask a Lisp programmer, he would say definitely. Can you do without? Of course.

- Josh




0

Share this post


Link to post
Share on other sites
quote:
Original post by Krippy2k
Maybe I''m missing something here, but it sounds really simple to me. You write one function that sets everything to your defaults, and call it before you set your mode specific values. This is basic programming.

resetState();
enableLighting();
enableStencil();
etc...

How is that more error prone than creating a ''little language''?


If enableLighting throws, then your program is in trouble. You may need to unwind the enabled items and release components accordingly before quitting. Encapsulating the enables into a single common function that accepts keyword arguments will be more extendable and less likely to have bugs.
0

Share this post


Link to post
Share on other sites