Debug build of Mushroomstew

edited October 2011 in Help request
Can someone tell me how to make a debug build of the Mushroomstew game?

I downloaded the archive here:

When I try to make a debug build, it complains about missing orxd.lib.

When I build orx from source and try to use the resulting orxd.lib to build the Mushroomstew debug, there are errors about unresolved externals.


EDIT: Sorry, I should've mentioned Windows platform, MSVC2010


  • edited October 2011
    Hi acksys,

    Unfortunately that won't be that easy! Mushroom Stew is almost 2 years old and orx/Scroll evolved quite a lot since. :)

    One option would be to sync orx's SVN to an a version of the same period (~january 2010) and compile it.

    I'll try to have a look and to adapt Mushroom Stew for a recent version of orx if you're interested. But I won't be able to do that before a good week as I won't have much access to my computer till then.
  • edited October 2011
    Thanks, iarwain. I'm mainly interested because I want to use orx to draw tile-based screens and I'd prefer a map editor rather than editing the config files by hand.

    I will try to build an old version from svn and link against that.
  • edited October 2011
    I see. The editor part of Scroll has been much improved since Mushroom Stew. In addition to many fixes it also supports object catalogs which makes the edition less annoying.

    I'll probably host Scroll on for those who want to get a recent (and regularly updated) version.
  • edited October 2011
    Thanks. If you would make that available at your convenience, I would appreciate that.

    I am new to gamedev and still fairly new to C++ programming in general, and I have worked sporadically on a Windows/Linux tile engine for about a year now ( This project has support for maps created using the Tiled Map Editor (

    I would very much like to use the Orx engine for the mobile game my creative partner and I have designed. So after looking at the Orx map editor source code, I can decide whether to use it or to implement a way to export Tiled maps to Orx config format :)
  • edited October 2011
    I'll let you know as soon as it's ready, hopefully next week end. I'll also look at crawl at the same time. :)

    As for the map editor I know that some people were using it with orx and simply converted its output to a config-friendly format they could then load into their game. I don't have any code for that myself though, but I'm sure it shouldn't be too much of a trouble to write such a converter.

    Also Scroll is not exactly tile-oriented, it can do tile-mapping but it was created to be more of a freeform editor, like Aquaria's one (
  • edited November 2011
    Have you had any time to prepare this? I would love to take a look when it's ready.

  • edited November 2011
    I'm afraid not. I barely touched my home computer since last time. :(
    I'll try again next week end... :)
  • edited November 2011
    Well, I finally took the time to update it last night. It's working not too bad but I still have some bugs to fix (like random untriggered shooting after landing or bullet being spawned slightly to the side sometimes).
    But if you want to try it in its current state, you can find it here.
    I've only added pre-compiled files for msvs2008 but you should be able to compile it for any platform using the latest version of orx from svn.
  • edited November 2011
    Great, thanks for doing that! I'm excited to look at it.
  • edited November 2011
    My pleasure!

    Beside the bullet bug (animation related I think), please note that this game was written for a TIGSource compo 2 years ago, in about 20-25 hours so there are a couple of things to keep in mind:
    - orx and scroll both have evolved quite a lot since then and MS could benefit of some new features to be written more efficiently
    - assets were defined for the compo and we could pick among all what was created by the artists in the first part of the compo but couldn't alter any resource: that means that I had to adapt the code to handle some of those constraints and the end result isn't as effective as it'd be if the assets were made especially for that game
    - due to the short development time, I sometimes took some shortcuts that are not the best design choice
    - I suck at game & level design, so the end product isn't that good but that was still fun to make (especially playing with shaders :))

    If you have any questions, don't hesitate!
  • edited November 2011
    Thanks again. I had some free time on a 2.5 hour flight last week. I was able to build the project in MSVS2010 with very few modifications to the .sln. I went through the game loop with a debugger. I can see how the Scroll code adds a level of convenience.

    It's good to see actual Orx game code in action. The tutorials in the Wiki are great, but a lot of the examples are trivial so it's good to see how someone might actually build a game by studying a longer example.
  • edited November 2011
    I'm glad it was of any use to you. But again, keep in mind that this game optimally coded by any stretch due to the time & resources constraints. But at least it can give an idea how things can be done with Scroll. :)
  • edited November 2011
    As Scroll can be found in this thread, I'm going to post the "instructions/doc" I usually send to people when sending them a version of it:
    So please find Scroll attached to this email. You don't need to keep the same folder structure The important files are the ones in the /include and /data folders. Also please not you need the latest version of orx from the SVN so as to be able to use it as they're more recent than the latest release packages (1.3 rc0).

    Please find below the instructions/explanations on how to use it:

    You first need to include Scroll.h wherever you need it, but you'll specify your implementation only in one place by defining __SCROLL_IMPL__. For example:

    MyGame.h =>

    #include "Scroll.h"

    MyGame.cpp =>

    #define __SCROLL_IMPL__

    #include "MyGame.h"

    #undef __SCROLL_IMPL__

    This way Scroll's implementation will only be in MyGame.cpp, nowhere else.

    Your game class needs to extend Scroll this way:

    class MyGame : public Scroll<MyGame>

    In there you can override all the virtual methods you need (at least the Init and Run ones otherwise your game will stop as soon as you launch it =) ).

    In the main() function of your game, simply call
    MyGame::GetInstance().Execute(argc, argv) to run your game.

    For all your game objects, you need to inherit from the ScrollObject class. It doesn' t have to be a direct inheritance. For example you can have:

    class Character : public ScrollObject


    class Player : public Character

    For all your objects, you then need to bind the config section to the C++ class in the method MyGame::BindObjects() (that you override from Scroll).

    Here's an example:

    void MyGame::BindObjects()


    for(orxS32 i = 0; i < orxConfig_GetListCounter("VillagerList"); i++)
    ScrollBindObject<Character>(orxConfig_GetListString("VillagerList", i));


    Let's say we have
    VillagerList = John # Lise # Paul

    This will bind the class Player to the config section Bob and the class Character to the sections John, Lise and Paul.

    Everytime you want to create/delete an object, use the methods of your game class called CreateObject() and DeleteObject() instead of orx's ones.
    Each time you call CreateObject("John"), your return is actually a Character class and you can cast it safely with ScrollCast<Character>() (in debug it'll make some verifications). Or simply use the convenience wrapper:
    CreateObject<Character>("John") that will do both the creation and the checking/casting.

    Even if an orx object is created by someone else, or indirectly via a spawner for example, the corresponding C++ class will still be instanciated and bound.

    When an object is created its OnCreate() method is called. There's a bunch of other methods called for events (such as changing animations, physics collisions or even Update()) for all objects. You can add your own if you want of course. This is usually less annoying than adding an event handler. =)
    When you're in a object's callback methods, its model config section is always pushed (See the ScrollObject::PushConfigSection() method) so you can query config properties directly.
    Also, if you need to parse the collections of objects, you can use MyGame::GetNextObject()/MyGame::GetPreviousObject().

    If you don't want to compile the editor, before including Scroll.h, just define #define __NO_SCROLLED__

    Otherwise, you can launch the editor by adding "-editor" on the command line of your game.

    If you want your objects to be placeable in the editor, in their config section add:

    ScrollEdSet = <NameOfTheSet>

    So for example:

    ScrollEdSet = Villager

    Will place the object John in an editor catalog page named Villager.

    Here are the commands of the editor:

    - mouse wheel cycles through catalog sets (property ScrollEdSet in the objects you want to be able to place in ScrollEd)
    - left clic: either instanciate your cursor object or pick the object
    under the cursor
    - right clic + drag: no selection: move the camera, with a selection:
    edit the object
    - middle clic: copy the object under the cursor, including its color,
    tiling, alpha, ...
    - space: clear the cursor selected object
    - Delete/backspace: deletes the selected object
    - Z, X, C: change the edition mode (move, scale, rotate)
    - Q, W, E, R: keep pressed to edit the color/alpha of the selected
    object and move the mouse horizontally (Q = red, etc...)
    - G: turn on/off the display of the grid
    - S: stick edition: for move (on the grid), scale (multiple of the
    original size of the object), rotate (every 45°)
    - A: change the smoothing mode of the object
    - D: turns differential scrolling on/off
    - T: turns tiling on/off (mirroring is achieved by scaling negatively)
    - ctrl + mouse wheel: changes the edited layer
    - ctrl + right clic: control the camera zoom
    - tab: resets the camera zoom
    - F5: starts the game (and saves the map)
    - F4: stops the game and go back to edition
    - F3: toggles fullscreen
    - F12: takes a screenshot
    - Esc: quits

    There are UI buttons on screen for most of those though and using the
    shortcuts will affect the button state. There's no undo, so the editor
    is autosaving the map every minute or so. You can specify which map to
    edit on the command line (-map MyMap).

    You can ask the editor to save encrypted maps by changing the
    ScrollEd::EncryptSave config option.

    If you have any questions, please let me know! =)
  • edited November 2011
    Thanks iarwain!
  • edited November 2011
    My pleasure!

    I'll try to fix the remaining bugs soon-ish in order to have something clean for people to play with. :)
Sign In or Register to comment.