Just passing by...
Daniel "MontyOnTheRun" Monteiro
Recent community posts
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.
Core 2 Duo CPU E7400 @ 2.80GHz
Intel HD Graphics
It's not such a bad machine - compiling C++ is a breeze.
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.
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?
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.
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.
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.
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...
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
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!")
Oddly enough, now it seems to be working well. But maximing it makes everything look stretched and displaced.
I'm loving the dialogue!
EDIT: now I've realized that the initial window size is also not optimal. The commands at the top were missing. Having resized it manually, it's perfect now.