Loderunner clone
Community Forums/Showcase/Loderunner clone
| ||
| Thought I'd post some screenshots of my loderunner clone. They're not that exciting, cause, well, they are Loderunner and I'm using graphics like the original. But here they are. Game's coming along quite well, couple of defects to nail out, and need to add demo and edit mode and it will be ready. [EDIT: I've since added a downloadable, testable version below for those who can try it on the Mac to see if it works so far..]    |
| ||
| the link is broken... I think you need the "http://" infront of the url.. but I pasted it in the browser.. looking very nostalgic.. :) |
| ||
| Ahh OK, I was trying to work out the BBCode or such, but it didn't need it. Just stick the url in there...Should work now. |
| ||
| Lode Runner was one of my Apple II favourites. It'll be nice to play it on an Apple machine again. :) Barney |
| ||
| Hahahaha Barney! I didn't think of it like that as I use a PC. I think though, that the original will still be better - my version was written to showoff an A* pathfinding module I've written for Blitzmax, so the pathfinding is different to the original. I'd like to get hold of the original Apple assembler code and reverse engineer the same routines for a more accurate port version. Aaron |
| ||
| Hi guys. I was wondering if any of you can try and test my Loderunner clone on the Mac? I've been doing PC development, but I'd like to see how it's holding up on the Mac so far. There are a number of bugs you will definately find as they are with the enemy AI mainly. In the Zip, there is a loderunner zip which is the code, and there is an astar.mod zip which has to go into the pub.mod mods directory under a directory astar.mod. You'll have to do a makemods on it for that to build. Let me know how it goes. Also, the code needs a bit of tidying up and refactoring so ignore that...I'll get round to that when it's near completion :) http://homepages.paradise.net.nz/akoolen/loderunnergame.zip Thanks and let me know if I've forgotten something. Aaron |
| ||
| Downloaded. Looks like I'll be popping into office over weekend to give this one a go on the real Mac - not the PearPC substitute. BTW. Aaron, if you want to try a real good Loderunner conversion for PC, check Spoonbill Software site run by Ian Humphreys. He also has some other Apple II conversions there, all for free. Here's the URL: http://www.omninet.net.au/~irhumph Barney |
| ||
| compiles and runs... Compiling:Human.bmx Compiling:Player.bmx Compiling:AStarRunner.bmx Compiling:Enemy.bmx Compiling:LoderunnerBlockView.bmx Compiling:Loderunner_new.bmx Linking:Loderunner_new.debug Executing:Loderunner_new.debug when I hit space to start I get: Unhandled Exception: Attempt to index array element beyond array length DrawImage [$BMXPATH/mod/brl.mod/max2d.mod/max2d.bmx;263;2] drawBlock [/Users/dave/Archives/loderunnergame/Loderunner/LoderunnerBlockView.bmx;165;3] draw [/Users/dave/Archives/loderunnergame/Loderunner/LoderunnerBlockView.bmx;53;5] circle [/Users/dave/Archives/loderunnergame/Loderunner/Loderunner_new.bmx;322;4] circleIn [/Users/dave/Archives/loderunnergame/Loderunner/Loderunner_new.bmx;309;3] run [/Users/dave/Archives/loderunnergame/Loderunner/Loderunner_new.bmx;93;3] Loderunner_new [/Users/dave/Archives/loderunnergame/Loderunner/Loderunner_new.bmx;38;1] didn't look into it, gotta go [edit] reformatted this message slightly |
| ||
| Hmm, well that's in the block graphics loading call. Strange, because for the incbins to work the blocks should be there. I wonder if the Mac needs different paths and things for the executable? When you run it I assume it runs from that directory and not another one? Cheers Aaron |
| ||
| ok, I'm finding it difficult to figure this one out because the debugger isn't popping up. Anyone know how to put a stop in? Anyway, the DrawImage is getting the index from _map.getMapBlock(x,y). it errors on what could be a random number or an address location?? I'd guess random, maybe the map is not getting filled right? The file is being found and read. |
| ||
| Aaron, you have Method _loadMap(mapNumber) Assert(_map) What does this Assert do? I was under the impression that you assert in BMax only works in an expression such as: Assert alpha>=0 And alpha<=1 Else "Alpha value out of range" |
| ||
| dmaz: DebugStop will invoke the debugger. |
| ||
| great, i'll check that out now. |
| ||
| ok DebugStop just exits the program... help says "If there is no debugger present, this command is ignored." so I guess I don't have a debugger present? I was assuming the dubugger is part of BlitzMax...? |
| ||
| Hey, It works! Only one problem: The 'ReadFile()' functions in the main file need a 'littleendian::' in front of them, eg:
Local file = ReadFile("littleendian::lvldat")
If file = Null
file = ReadFile("littleendian::"+rootPath + "lvldat")
EndIf
Assert file, "Error opening lvl.dat file"
But apart from that, sounds are OK, all looks honky dory. This is another thing - like case sensitive file names under UNIX filesystems - I was unsure whether it was worth trying to automate. In the end, I couldn't really work out how - forcing a stream to be littleendian or bigendian by default seemed a bit heavy handed. But these are the only 2 major cross platform issues that seem to arise. The solutions are pretty simple: Beware of cased file names (or even easier, stick to lowercase only!), and use "bigendian::" or "littleendian::" for all binary data streams - doesn't matter which, as long as its consistent. A note about the debugger - it doesn't work (yet) in full screen. But you can use a graphics depth of '0' to force a debugger friendly windowed mode for development. [edit]Killed your Loadmap report, dmaz - above should fix it[/edit] |
| ||
| dmaz. Assert just throws a general exception if the expression inside it fails. It's a simplified form of the one you presented. I'm starting to wonder if the problem is endianness. Can you try changing Local file = ReadFile("lvldat") To Local file = ReadFile("littleendian::lvldat") And see if that works...I'd imagine it will have some effect cause almost all file io with reads of non bytes will require this - an oversight on my part so far. Thanks for the help Aaron |
| ||
| Haha, looks like we posted at the same time Mark - glad to see it works now. One thing, I've noticed, dunno if it's like this on the Mac, is that the iris in and out effects seem to flicker some of the background through, dunno if that's a bug, or a double buffer issue or what. No biggie tho, there are more pressing issues with it than that ;) Aaron |
| ||
| OK, there is another version up there with the endianness in there. |
| ||
| Ok cool that work, the game runs fine. The debugger works great also! so then for situations like this would you do something along these lines? ?MacOS Local file = ReadFile("littleendian::lvldat") If file = Null file = ReadFile(rootPath + "littleendian::lvldat") EndIf ?Win32 Local file = ReadFile("bigendian::lvldat") If file = Null file = ReadFile(rootPath + "bigendian::lvldat") EndIf ? that works, is that the perfered way... adding linux of course |
| ||
| so then for situations like this would you do something along these lines? No need for all the '?MacOS' stuff - just pick one and stick with it. All the '?' kludges are in the endianstream module: see mod/brl.mod/endianstream.mod/endianstream.bmx for the nitty gritty. |
| ||
| oh yeah, duh it's the file that matters. I should of got that. little slow today. |
| ||
| Thanks for your help dmaz. Glad to hear it's running OK - that was rather painless after all! Cheers Aaron |
| ||
| I have a couple of Qs: Is PowerPC (MacOS / Linux) big or little endian? Is X86 (Windows / Linux) big or little endian? Does endian-ness in these cases apply to just the order of the bytes or the numbering of the bits within the bytes as well? |
| ||
| x86 are little endian. most processors from motorola were/are big endian. the PowerPC was an Motorola/IBM design. And of course the old Amiga's were big endian as well. Big endian is smarter and better ;) but I still like windows better. |
| ||
| Endianness just applies to byte ordering, not bit ordering. Aaron |
| ||
| Am I the only one who has problems with this game? It runs fine, however after playing for a short time (at first I thought it was when climbing ladders, however it just happened when walking across the bottom platform) and program quits and I get OS X's "The application Loderunner_new.debug has unexpectedly quit." That's the file I'm meant to run isn't it? The game doesn't play for long - to give you an idea there is no way I could get above the 2nd platform in that time. It's happened numerous times so it isn't a one off. I re-downloaded the code but it didn't change anything. Any ideas? Fullscreen or windowed doesn't make a difference. I love Loderunner so I hope to get this working. It looks great! (OS X 10.3.6, Powerbook G4. I really need to put this in a sig.) |
| ||
| Hmm, that's really strange... On the Mac, is there a way to run the program from some sort of command line, and when it quits see if any debug or such message was reported? Maybe I need to buy a Mac - good excuse to...;) Cheers Aaron |
| ||
| I thought I had fixed it but was wrong. I tried running it directly from the HD not in any folders (other than Loadrunner). Probably not connected but that game gave me the longest playing time - but it still quit. Note this is once again on a new install of your code and your module. OS X has a crash log if that's what you mean, one moment... The thing is, it isn't blitz handling an error and terminating it's the app just crashing. So I'm not sure how much help this would be. |
| ||
| Same thing happens with debug mode turned off. However - and I'm guessing this could be important - when I first tried to run it with debug mode off it wouldn't build saying this astar.a files weren't there. I had run it with debug mode off before, so I'm not entirely sure why this install of the modules didn't make them. So I turned off quick build and debug build and got the IDE to build the modules - which rebuilt all Max's modules and this time the .a files were there. However it still crashes. |
| ||
| Me again. I installed a fresh copy of blitz, fresh copy of your module and a fresh copy of your games code. Still crashes. I'm unsure what this could be on my end. Anyone have any suggestions? If someone with a mac that it worked on hosted a compiled version, do you think that would tell us anything? |
| ||
| you know I get the same.... didn't play it long enough before. |
| ||
| Aaron, Are you using any MemAlloc/Ptr stuff, or is it all 'strict Blitz'? |
| ||
| I don't get why files should open in different endianess on different platforms, I can't think of a single example where this would be useful other that it being somehow "politically correct" to make binary streams default to be incomaptible between platforms. Enidox, can you try disabling all the sound routines? Also, any chance it could be a screensaver or someother background app launching during play? |
| ||
| Commented out all channel and sound references (including the variables so I don't think I missed any) and it made no difference. Quit all other programs but Blitz IDE and that makes no difference. Could be a background app...but I doubt it. Note that dmaz is having the same problem. Plus, even if it was a background app that doesn't change anything - other than help track down what causes this. I don't have a screensaver on and judging by the short about of time the game runs before quitting, it doubt anything has time to activate. |
| ||
| Ok, I think its happening when a hole has just filled itself in - ie: disappeared. Ok, just did further testing and it looks like array indices are *not* picked up in debug mode - very naughty! This would suggest that you're drawing a hole with a frame number of -1 or something. |
| ||
| I just found that out too, but have been wondering why this doesn't happen on the PC. It happens in LoderunnerBlockView.bmx in the draw method. One moment... |
| ||
| That's it: DrawImage _holeGraphics, _map.blockXToWorldX(hole._x) * _worldToViewScaleX + _offsetX, _map.blockYToWorldY(hole._y) * _worldToViewScaleY + _offsetY, hole.getAnimFrame() hole.getAnimFrame() returns -1 [Edit] I'm still wondering why this hasn't been picked up on PC... |
| ||
If anyone REALLY wants to play loderunner (though I'm guessing it's just me), change the getAnimFrame method in Hole.bmx to:Method getAnimFrame() If _animFrame<0 Return 0 Else Return _animFrame End If End Method Sure, it's cheep and may just be masking another problem but since it's not my code and it lets me play I'm happy. |
| ||
| Well thanks for debugging. Yeah Mark, strange it hasn't picked it up that's for sure! I'll see if I can find where, logically it has gone wrong and fix it. Thanks Enidox for all the effort! Cheers Aaron |
| ||
| OK, found a couple of obvious bugs, strange they never showed up in the PC version. The timer that counted down the holes states, would get to -1 which means one more loop of the anim update! Also the countdown for the anim was counting down in bigger steps assuming one more frame of animation than there was! Fixed now. Not uploaded yet as I want to fix a couple of other bugs. |
| ||
| OK, new version up at the link at the top. Fixed a number of bugs causing the enemy to just stop working. There is still one lurking when enemies are stacked and fall together, especially when the bottom one falls in a hole. In this case the top one never gets to move again. Aaron |
| ||
| This is a great recreation of a great game. The bugs from before are gone now. One point, initially it wouldn't compile saying FontHeight() in your drawDebugInfo function didn't exist. I'm guessing the name of that function has changed to TextHeight() for the final mac release? I still have a few apples lying around...this makes me want to go searching boxes for the LodeRunner disk. :) Great work once again! |
| ||
| Thanks enidox - and thanks for the update on FontHeight - You're probably right about the command change. Aaron |
   |