Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

Daniel "MontyOnTheRun" Monteiro

115
Posts
52
Followers
103
Following
A member registered Mar 31, 2016 · View creator page →

Creator of

Recent community posts

Congrats on your game - it's no easy feat to ship a game for DOS. And you managed to keep a very good file size!

Did some tests on my machines:

486DX 50Mhz 12MB RAM = runs a little laggy, but playable.

486SX 33Mhz 8MB RAM = crashes at startup due to the lack of math co-processor.


Since Lua Number is a 64-bit floating point, your game will require floating point emulator (if you're using DJGPP, add -lemu at your linker command line).

This is also most likely the reason for the lag on my 486DX and also your known bug. But hey, there is a way around it! If you want, I can help you change Lua Number into a 32-bit integer (and most stuff will still work).


My lastest game, The Mistral Report (https://montyontherun.itch.io/the-mistral-report) also uses Lua (5.2), which I modified to use (almost) no float. At the end of the day, I had to add -lemu, but it's perfectly playable on the 486SX)

Just passing by...

Many thanks! It worked!

Frame rate was all over the place and there were some texture coordinates mess up when closer to the near clipping plane, but all in all, it worked. I couldn't test with sound, but the console outputted a lot of errors regarding it.

Machine:

  • Core 2 Duo CPU     E7400  @ 2.80GHz

  • 2Gb RAM

  • Intel HD Graphics

  • SSD

  • Xubuntu 64-bits

It's not such a bad machine - compiling C++ is a breeze.

Could not get it to run on my Xubuntu 64-bits - any idea what could be done?

(1 edit)

Three key points that might help:

  • Try to use consecutive memory accesses as much as possible, to maximize cache coherence.
  • Avoid floating point like the plague - even on DX machines.
  • Allocate memory upfront and try to recycle it as much as possible.

EDIT: it doesnt work on my 486DX 50mhz, 12 MB RAM. In my Raspberry Pi 3, with DOSBox (my main development machine) it's stuck on the hourglass (but to be fair, my game runs quite slowly on that machine as well).

Hey Jim - nice to see you around here! Thanks for taking the time.

My first attempt was a Raycasting engine, and while the speed was actually quite nice, I felt it would constrain the kind of environment I wanted to create. To be honest, never considered sprinkling some raycasting into later implementation.

That video you saw was from the SDL version, with me performing a flip on the video surface on every pixel, to help me debug stuff. I actually draw to offscreen buffer first and only then send everything to VRAM. To be fair, there was a fair amount of sloppy level design in there was well.

For my next project (The Mistral Report), while I did employ this same visibility algorithm, other options are still on the table. One thing I want to try is having a 1D Z-Buffer (Doom did that, AFAIK) for every column on the screen and perform the drawing front to back. Or simply go for portals-on-volumetric-sectors for good?

Finally, there is the undeniable bloat legacy from this engine being an port from a Android game I wrote while learning C++14. No wonder the binary end up with 800KB, while the rewritten engine for The Mistral Report is almost pure C99 and only has 150KB or so. Writing code for 486s was eye-opening.

Parabéns!

You should consider adding support for OPL2LPT or OPL3LPT (it's quite easy to modify  Adlib code to support it - let me know if need any help with that).

Is there any minimum requirements?

Twice, indeed! Very nice!

Thank you for notifying me.

https://github.com/dreamlayers/em-dosbox/

If you need help following these steps, let me know

Please, do whip out some awesome Pascal!

I firmly believe we didn't explored the 486s well enough. And Pascal could use some vindication as well.

Hope you had a good time playing. Its a simple game, but gives me great sense of accomplishment and will help testing the grounds for something bigger.

isnt this backwards?

Gonna try tomorrow ;-)

Looks awesome! Would a Linux version be possible?

I was playing on a Mac ;-)

With Code Blocks, there is a clear option to link statically. Maybe you got this as well?

Is it DirectX? SDL? SFML? ...GDI 😏

Oddly enough, I used to have Visual Studio 17 installed on this machine. What did you use to create your game?

Kind of 2-3 seconds per frame, mostly, TBH. Sometimes it went better, like 2-3 FPS

I remember the settings already being at the lowest - I was actually quite impressed by both that being the lowest setting and still looking amazing and by it being capable of detecting the need of the lowest setting. I believe to have closed everything.

To be fair, the art was taken from the open source roguelike Stone Soup and is Creative Commons - so anybody can use it.


Thanks for playing :)

Screen goes black once I enter fullscreen (Onda V80 plus tablet. running Windows 10 64-bit).

Who doesn't love a fart noise now and then? =P Had fun playing it. My only gripe is the download size.

I used to do a lot of this kind of stuff when I was learning. Good memories!

Hint: you can make it browser playable by using the Emscripten port of DOSBox. For action games, it's not very good, but for turn based, it's almost acceptable (check my entry to see what I mean)

Sorry, but I don't understand? I click and press keys, but nothing happens (other than a cube falling and a countdown). What's supposed to happen? What should I do?

I have to also report you that it was kind of sluggish on my Win10 64-bit tablet.

On my Windows 10 64-bit tablet, it complained about VCRUNTIME140.dll and MSVCP140.dll and refused to run. Any tips?

Spooky! I can't handle this! XD

Very well made!

It's all the good parts of Choplifter without the bad parts, but also with a pinch of BroForce! Amazing!

Wait...doesn't run on DOS?! =P

Nice graphics! I couldn't shoot the left wall in one of the levels (it would open my OSX dock) - I was under the impression that the screen resolution didn't really fit my monitor all that well...

Interesting art direction and set of choices. What were the castles used for backdrop?

Really good game! Is there any way to avoid being hit by the green wave attack from the crystal? I also couldn't find any way to quit the game...

While I coulnd't particulary relate (maybe I'm from another generation/culture), this is quite well made. Quite cool!

I couldn't get voice for the love of god here. But the music was very cool indeed. Not my style of game, but very well made, none the less.

Tried again on my Mac Mini, but got an error. First, I had to give the Unix binary permissions, but then I got the following messages:

dlopen /Users/monty/Downloads/CherryCreekDemo_osx64/cherrycreekdemo.app/Contents/MacOS/./../Versions/64.0.3282.119/nwjs Framework.framework/nwjs Framework: dlopen(/Users/monty/Downloads/CherryCreekDemo_osx64/cherrycreekdemo.app/Contents/MacOS/./../Versions/64.0.3282.119/nwjs Framework.framework/nwjs Framework, 257): no suitable image found.  Did find:
/Users/monty/Downloads/CherryCreekDemo_osx64/cherrycreekdemo.app/Contents/MacOS/./../Versions/64.0.3282.119/nwjs Framework.framework/nwjs Framework: file too short
/Users/monty/Downloads/CherryCreekDemo_osx64/cherrycreekdemo.app/Contents/Versions/64.0.3282.119/nwjs Framework.framework/nwjs Framework: file too short
Abort trap: 6

Ran way too slow on my Mac Mini Late 2012 (Core i5), High Sierra. Graphics looked quite nice. There was no way to play it, unfortunately.

WOW! Trippy! I liked it!

BTW, not sure if it's only with me, but on my Mac, I had to open the .app and give execution permission to the Unix binary. It's the second Unity game today I see having to do this - maybe it's Apple forcing our hands into signing with them?

There is some sheer elegance to be appreciated here. You (rightfully) resisted the urge to use some big monster engine and went with Java.  We end up with a fun game that's a 12KB download instead of some huge 20MB. And I thought my game was compact!

I applaud you standing.

Tried to run on my Mac Mini Late 2012 (Core i5), running High Sierra.  The .app file wouldn't run, so I entered it (it's a folder pretending to be a file , after all) and give execution permissions to the Unix binary file. It ran but was slow as molasses on the main menu. It hanged during the loading screen (eternal volleyball). Since I was running from terminal, I've got the error messages ( https://gist.github.com/TheFakeMontyOnTheRun/569bc346f2d13fbddddfb836ce58dc93 )  - there were many more.

A small note: the keyboard layout doesn't make it very clear what the inventory and run keys are supposed to be. Bear in mind that there are a lot of different layouts out there, even between countries that speak the same language (eg: I use both Brazilian and Portuguese layouts and it's astonishingly different).

Too bad I couldn't play, but hopefully this will help tracing the source of this issues.

Knowing each operating system to use would also help. I have all the options, but knowing where to download helps a lot.

Also, properly labelling the folder also helps. I unzipped on my Mac and got a "Release" folder.

Gonna give it a proper review later - when I'm on Windows.

Oddly enough, on OSX it starts on fullscreen and if you go to the settings menu, do nothing and go back, it will switch to windowed mode. If you again into the settings menu, it is set as fullscreen. You have to unset and reset.

Other than that, a very enjoyable game. Very well made!

As long as it is a finished prototype, I believe it's valid; but I will certainly judge it against the merits of a prototype in comparison to a completed game, the effort I expect from a jam of this length and the quality of other entries. I also tend to take into consideration the tool and what would it allow the creator to do and how long before the deadline it was submitted.

To sum it all - I like to recognize effort; if I reward lazy entries, there is no incentive for others to grow.

Hope this doesn't feel too harsh (what can I do - I'm an old fart... "now, get off my lawn, damn kids!")