Metronome
Learned
- Joined
- Jan 2, 2020
- Messages
- 277
It's very effective. Zorbus has the most natural looking dungeons in any roguelike I've seen.
-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Vapourware Codexian Game Development Thread
- Thread starter 20 Eyes
- Start date
TheDeveloperDude
MagicScreen Games
- Joined
- Jan 9, 2012
- Messages
- 411
I have managed to create the virtual chaos. https://youtu.be/810kBncr8tQ
Do I need a bigger battlefield?
Do I need a bigger battlefield?
The Avatar
Pseudodragon Studios
I have finally announced my game that I have been posting here for the past year a half
Thread- https://rpgcodex.net/forums/threads/archquest.138705/
Thread- https://rpgcodex.net/forums/threads/archquest.138705/
- Joined
- Mar 25, 2012
- Messages
- 2,226
Uploaded a tool i wrote ~16 years ago when making Nikwi, a small 2D platformer (which was ahead of its time in that it was very hard despite its cutesy looks and had all that retro pixel art charm but was released 5-6 years before that stuff became popular so it never made any sales and a year later or so i just gave it away for free with source code - nowadays it is part of several Linux distros and had some nice comments before people got spoiled with Steam, etc, so there is that at least).
The tool is a simple sound effect generator and is basically a clone of some old shareware tool i found in a CD somewhere... though i haven't seen it for 16 years and do not remember its name at all :-P. It isn't really anything special, nowadays there are better tools, but i found the code on an archive i had on an old PC of mine and decided to make a fresh build, fix a couple of bugs and upload it. If nothing else, it can be used to edit those .ssfx files that are part of Nikwi (not that anyone will bother but anyway :-P).
It can be found here (along with some samples): http://runtimeterror.com/tools/ssfx/
- Joined
- Mar 25, 2012
- Messages
- 2,226
In completely unrelated news, i fixed Post Apocalyptic Petra's Direct3D backend to do better texture format use (actually i mostly had it but i accidentally ended up hardcoding the values - probably some debugging code i forgot to delete). So now the game runs on S3 Virge too, here is a before the fix and after the fix on S3 Virge:
I've also made a few other improvements, mainly optimizations for the software renderer and fixes for the sound playback - especially improved on DOS where regardless of the framerate the sound keeps playing normally instead of being choppy (sadly i haven't figured out a way to do that on Windows, though it still is much better than previous version). I've made a bunch of changes though and i want to test it in all the other platforms before uploading a new version.
In the meanwhile, i improved my Free Pascal profiler for Windows to add call stack capturing (the window here shows a capture from Little Immersive Engine - yes there are a lot of box visibility checks :-P):
By doing that i can easily find from where exactly a "hot" function is called. This sort of functionality (or at least the way i'm using it) is something i miss in most profilers and the only other i only know that seems to work like that is Luke Stackwalker - which also has neat graphs - but the project has long been abandoned and it doesn't even compile without major changes to its wxWidgets use (it uses a much older version). Also it only supports PDB files so it is only usable for Visual C++, which doesn't help me at all (i wouldn't make my own profiler if i could use PDB :-P).
The new version (1.1) also adds a few other minor features, like copying individual function names to clipboard and searching for text in the results list.
I've also made a few other improvements, mainly optimizations for the software renderer and fixes for the sound playback - especially improved on DOS where regardless of the framerate the sound keeps playing normally instead of being choppy (sadly i haven't figured out a way to do that on Windows, though it still is much better than previous version). I've made a bunch of changes though and i want to test it in all the other platforms before uploading a new version.
In the meanwhile, i improved my Free Pascal profiler for Windows to add call stack capturing (the window here shows a capture from Little Immersive Engine - yes there are a lot of box visibility checks :-P):
By doing that i can easily find from where exactly a "hot" function is called. This sort of functionality (or at least the way i'm using it) is something i miss in most profilers and the only other i only know that seems to work like that is Luke Stackwalker - which also has neat graphs - but the project has long been abandoned and it doesn't even compile without major changes to its wxWidgets use (it uses a much older version). Also it only supports PDB files so it is only usable for Visual C++, which doesn't help me at all (i wouldn't make my own profiler if i could use PDB :-P).
The new version (1.1) also adds a few other minor features, like copying individual function names to clipboard and searching for text in the results list.
In the meanwhile, i improved my Free Pascal profiler for Windows to add call stack capturing (the window here shows a capture from Little Immersive Engine - yes there are a lot of box visibility checks :-P):
By doing that i can easily find from where exactly a "hot" function is called. This sort of functionality (or at least the way i'm using it) is something i miss in most profilers and the only other i only know that seems to work like that is Luke Stackwalker - which also has neat graphs - but the project has long been abandoned and it doesn't even compile without major changes to its wxWidgets use (it uses a much older version). Also it only supports PDB files so it is only usable for Visual C++, which doesn't help me at all (i wouldn't make my own profiler if i could use PDB :-P).
The new version (1.1) also adds a few other minor features, like copying individual function names to clipboard and searching for text in the results list.
Really nice. How come I've never heard of Luke Stackwalker before ? Just tried it and it is really straightforward. Will use when I need profiling.
- Joined
- Mar 25, 2012
- Messages
- 2,226
Yeah, i found it many years ago when trying to find a profiler for Visual C++. I actually had to do my own port to newer (for 2014 or so) wxWidgets because it was crashing with the application i was trying to profile and other tests i had made had convinced me that its approach was good enough to warrant the time spent. But the port was kinda sloppy and at the time the project seemed dead so i didn't submit it.
Interestingly i just noticed that there have been a new version last month that has some fixes (perhaps including the crash i mentioned) and ports to a new version of wxWidgets.
Do you know if there is a way to make function names appear instead of addresses ? Load source does not seem to do much appart from printing the code.
- Joined
- Mar 25, 2012
- Messages
- 2,226
I haven't used it in years, but i think it should pick it up from the PDB file. Perhaps you need to explicitly set up the paths to the PDB files?
There is a manual in the program's website: http://lukestackwalker.sourceforge.net/
- Joined
- Mar 25, 2012
- Messages
- 2,226
So, here comes yet another Post Apocalyptic Petra update: version 0.99n. This is largely an improvement on the audio side, especially under DOS when running the game with slower CPUs, but also improves performance a bit on the software rendering (mainly an oversight when it came to palette use). As mentioned previously i also fixed the texture format handling on Direct3D.
Also i took a video with the DOS version running on a Pentium 133MHz laptop a couple of days ago. It is with my shitty phone's shitty camera and i'm playing the game with one hand while looking through the phone's camera, so it isn't the best gameplay :-P but it shows that the game is actually playable there. It actually performs better than when running under the 86box PC emulator when configured to use a 133MHz CPU, so that is nice. On the other hand the sound does not work on the laptop despite supposedly being SB16 compatible, so that isn't nice. But working on that laptop is a PITA - i'll need to find an external keyboard and some PCMCIA card for somehow connecting to network or something to transfer files because transferring files to it can only be done with an external floppy drive.
Anyway here is the full changelog:
Also i took a video with the DOS version running on a Pentium 133MHz laptop a couple of days ago. It is with my shitty phone's shitty camera and i'm playing the game with one hand while looking through the phone's camera, so it isn't the best gameplay :-P but it shows that the game is actually playable there. It actually performs better than when running under the 86box PC emulator when configured to use a 133MHz CPU, so that is nice. On the other hand the sound does not work on the laptop despite supposedly being SB16 compatible, so that isn't nice. But working on that laptop is a PITA - i'll need to find an external keyboard and some PCMCIA card for somehow connecting to network or something to transfer files because transferring files to it can only be done with an external floppy drive.
Anyway here is the full changelog:
- Joined
- Mar 25, 2012
- Messages
- 2,226
This is really a case of "because i can" (i mean, the entire game is that, but this is even more): i spent my night making a quick and dirty port of Post Apocalyptic Petra to S3D, the original proprietary API that S3 Virge used (kinda like S3's glide except it existed before glide):
Actually as i mention in the video description i found another video with all the games that used S3D and wondered how hard can it be? Fortunately someone archived the S3D SDK on Vogons and so i downloaded it, noticed that the API is really tiny (though it relies on DirectDraw for memory allocation, etc) and also not very well documented (it does have a couple of examples that helped though), so i made a quick conversion of the header to Free Pascal and then a quick port using it. Since i do not have a real S3 Virge, i used 86box and ran Free Pascal and made the entire port in an emulated PC, but Free Pascal is fast enough to not be much of an issue.
There are still a few glitches and the game crashes the entire OS at the end (it only seems to happen with 32MB memory - i did all the development with 128MB of memory and never had the crash), so i'll try to fix that at some point - assuming i get the motivation again :-P. If not, i'll just keep it as part of the source code.
EDIT: in case anyone cares/is curious, i uploaded the S3D Pascal bindings i wrote on my site and also wrote some documentation for S3D itself.
Actually as i mention in the video description i found another video with all the games that used S3D and wondered how hard can it be? Fortunately someone archived the S3D SDK on Vogons and so i downloaded it, noticed that the API is really tiny (though it relies on DirectDraw for memory allocation, etc) and also not very well documented (it does have a couple of examples that helped though), so i made a quick conversion of the header to Free Pascal and then a quick port using it. Since i do not have a real S3 Virge, i used 86box and ran Free Pascal and made the entire port in an emulated PC, but Free Pascal is fast enough to not be much of an issue.
There are still a few glitches and the game crashes the entire OS at the end (it only seems to happen with 32MB memory - i did all the development with 128MB of memory and never had the crash), so i'll try to fix that at some point - assuming i get the motivation again :-P. If not, i'll just keep it as part of the source code.
EDIT: in case anyone cares/is curious, i uploaded the S3D Pascal bindings i wrote on my site and also wrote some documentation for S3D itself.
Last edited:
TheDeveloperDude
MagicScreen Games
- Joined
- Jan 9, 2012
- Messages
- 411
Why is it so hard to program the A.I. ?
Dumb scythians are building a huge fleet on a closed lake.
https://youtu.be/39fbdrd3zBM
:facepalm:
Dumb scythians are building a huge fleet on a closed lake.
https://youtu.be/39fbdrd3zBM
:facepalm:
I'm pretty sure you're the only one who can look at that UI and understand what's going on.
I'm working on an expansion for Himeko Sutori. I've been running into a lot of problems with ancient UE3 and the ancient Scaleform integration that lets the engine display ancient Flash files. The most recent problem I ran into was a difference in how UE3 and Flash assume that textures should be displayed.
I'm setting up a character sheet in Flash that will show your in-game character in the UI. Sending images from the game engine to Flash isn't that hard. But it messes up the color. On the far right is what the image is supposed to look like. On the far left is what it actually looks like when you first send the image to Flash. UE3 assumes that your textures by default are sRGB* and and therefore have most of the lighting detail in the darker areas. The game will convert your gamma-space sRGB image to linear-space before applying lighting, and it looks right under in-game lighting situations. You can tell UE3 that a texture is not sRGB, but then it'll look too bright when displayed in-game, with lots of blown-out highlights and lots of wasted color depth in the highlights that should have been used in the midrange.
*(UE3 also tries to reduce your texture file size by creating localized palettes for groups of pixels, which works well for most use-cases, but it doesn't work so great for consistent color in pixel art.)
When you send an sRGB texture to Flash, Flash doesn't know that it has a gamma curve applied and needs to be converted to linear space before display. So when you send that sRGB texture to Flash, it shows up too dark and saturated. To fix this, I could make copies of every single texture in the game, and save one as sRGB if it's intended for display in the game world, and save a copy as non-sRGB for display in the UI. I'm not going to do that.
Instead I came up with my own gamma correction in Flash ActionScript. I had to figure out how to access the bitmap's underlying data, and separate out the 32-bit integer into a bunch of 8-bit channels for red, green, blue, and alpha, and then apply a lookup table to adjust the color, and then bit-shift the results and put them back together into a single 32-bit integer. I thought the result looked pretty good. But then life slapped me in the face and I found out that although this is possible in the default Flash player, it's unsupported in the Scaleform integration. The method I use for tweaking bitmap color just doesn't exist in Scaleform.
So I thought I was screwed. Then someone over at the Epic forums told me that we all just have to do the best we can with the tools we have. Scaleform will let us change an image's color with adding and multiplying. It's not fine-tuned like a lookup table, but I figured if it's the only option I have then I'll give it a try. I set up some simple contrast reduction by multiplying the color by 0.7 and adding an offset. And I can live with the result. I just have to start with a darker background, and the result isn't too bad.
I'm setting up a character sheet in Flash that will show your in-game character in the UI. Sending images from the game engine to Flash isn't that hard. But it messes up the color. On the far right is what the image is supposed to look like. On the far left is what it actually looks like when you first send the image to Flash. UE3 assumes that your textures by default are sRGB* and and therefore have most of the lighting detail in the darker areas. The game will convert your gamma-space sRGB image to linear-space before applying lighting, and it looks right under in-game lighting situations. You can tell UE3 that a texture is not sRGB, but then it'll look too bright when displayed in-game, with lots of blown-out highlights and lots of wasted color depth in the highlights that should have been used in the midrange.
*(UE3 also tries to reduce your texture file size by creating localized palettes for groups of pixels, which works well for most use-cases, but it doesn't work so great for consistent color in pixel art.)
When you send an sRGB texture to Flash, Flash doesn't know that it has a gamma curve applied and needs to be converted to linear space before display. So when you send that sRGB texture to Flash, it shows up too dark and saturated. To fix this, I could make copies of every single texture in the game, and save one as sRGB if it's intended for display in the game world, and save a copy as non-sRGB for display in the UI. I'm not going to do that.
Instead I came up with my own gamma correction in Flash ActionScript. I had to figure out how to access the bitmap's underlying data, and separate out the 32-bit integer into a bunch of 8-bit channels for red, green, blue, and alpha, and then apply a lookup table to adjust the color, and then bit-shift the results and put them back together into a single 32-bit integer. I thought the result looked pretty good. But then life slapped me in the face and I found out that although this is possible in the default Flash player, it's unsupported in the Scaleform integration. The method I use for tweaking bitmap color just doesn't exist in Scaleform.
So I thought I was screwed. Then someone over at the Epic forums told me that we all just have to do the best we can with the tools we have. Scaleform will let us change an image's color with adding and multiplying. It's not fine-tuned like a lookup table, but I figured if it's the only option I have then I'll give it a try. I set up some simple contrast reduction by multiplying the color by 0.7 and adding an offset. And I can live with the result. I just have to start with a darker background, and the result isn't too bad.
Last edited:
TheDeveloperDude
MagicScreen Games
- Joined
- Jan 9, 2012
- Messages
- 411
Here is a longer gameplay video: https://www.youtube.com/watch?v=iN6adal5pD0
bionicman
Liturgist
- Joined
- May 31, 2019
- Messages
- 686
I clicked the link expecting not to get what's going on again, but I actually understand it now. It's just those placeholder graphics left a bad first impression on me, but the game seems a good concept (seems a sort of simplified 2d total war game?).
The second battle piqued my interest cause of all the different unit types. In contrast, the naval battle looked dull cause there is no information on what's going on (you could add some sort of a combat log or floating labels appearing above units indicating the damage inflicted on every shot). Also, adding more ship types (and in general other unit types), making it so the combat map is bigger with various terrain elements that influence combat (fortresses, forests, hills) would make it more interesting than it simply being about two armies clashing against each other head-on-head.
Anyways, like I said, seems like a good concept. I'm interested to see how it develops further.
The second battle piqued my interest cause of all the different unit types. In contrast, the naval battle looked dull cause there is no information on what's going on (you could add some sort of a combat log or floating labels appearing above units indicating the damage inflicted on every shot). Also, adding more ship types (and in general other unit types), making it so the combat map is bigger with various terrain elements that influence combat (fortresses, forests, hills) would make it more interesting than it simply being about two armies clashing against each other head-on-head.
Anyways, like I said, seems like a good concept. I'm interested to see how it develops further.
- Joined
- Mar 25, 2012
- Messages
- 2,226
So turns out despite thinking that Post Apocalyptic Petra works fine in S3 Virge it actually doesn't! The reason is that the game requests table-based fog support and S3 Virge doesn't support that. However i didn't know because 86Box, the emulator i used to test it, does not implement fog so it appeared that everything worked (though without fog, but i assumed it was just S3 Virge being S3 Virge). However since i noticed that fog doesn't work in the official S3D SDK i decided to check out 86Box's implementation and found out that it doesn't have any fog support at all.
So i implemented fog support on the emulator, here is a before and an after screenshot with my patch:
After having implemented fog support i decided to try Post Apocalyptic Petra again and it didn't work: the screen was completely black. Of course initially i thought that it was a bug with my fog implementation but after trying all the D3D examples and the S3D examples with all of them working, i decided to take a closer look at the D3D sample code and noticed that my fog setup is a bit different. The D3D examples only use vertex-based fog (which the S3 Virge supports) while i use table-based fog (which the S3 Virge doesn't support).
After changing the code to use vertex-based fog the game works fine (notice the fade to black at the distance):
I submitted a pull request for my patch so hopefully next versions of 86Box will have better S3 Virge emulation.
So i implemented fog support on the emulator, here is a before and an after screenshot with my patch:
After having implemented fog support i decided to try Post Apocalyptic Petra again and it didn't work: the screen was completely black. Of course initially i thought that it was a bug with my fog implementation but after trying all the D3D examples and the S3D examples with all of them working, i decided to take a closer look at the D3D sample code and noticed that my fog setup is a bit different. The D3D examples only use vertex-based fog (which the S3 Virge supports) while i use table-based fog (which the S3 Virge doesn't support).
After changing the code to use vertex-based fog the game works fine (notice the fade to black at the distance):
I submitted a pull request for my patch so hopefully next versions of 86Box will have better S3 Virge emulation.
TheDeveloperDude
MagicScreen Games
- Joined
- Jan 9, 2012
- Messages
- 411
I have done the minimap.
You can select a country on the minimap or scrolling by grabbing the map screen with the mouse.
The full map was better but if there is a lots of country then everything very tiny, and I can see nothing.
https://youtu.be/Op6CmLEjZao
You can select a country on the minimap or scrolling by grabbing the map screen with the mouse.
The full map was better but if there is a lots of country then everything very tiny, and I can see nothing.
https://youtu.be/Op6CmLEjZao
- Joined
- Mar 25, 2012
- Messages
- 2,226
Hey, i know this icon! It is LWJGL. What version is it?
rusty_shackleford
Arcane
- Joined
- Jan 14, 2018
- Messages
- 50,754
hehe boobies
The Avatar
Pseudodragon Studios
Started modeling again after having been in coding mode for the past several months. This is my version of a Kuo-toa, or a fat Murloc depending on how you see it. I think Kua-toa is Wizards of the Coast IP, so I will have to think of a different name for them. Any ideas?
RPK
Scholar
- Joined
- Apr 25, 2017
- Messages
- 339
Started modeling again after having been in coding mode for the past several months. This is my version of a Kuo-toa, or a fat Murloc depending on how you see it. I think Kua-toa is Wizards of the Coast IP, so I will have to think of a different name for them. Any ideas?
You're right, they're not not in the SRD.
Might I suggest:
https://getyarn.io/yarn-clip/71ba54c3-5bb0-43a8-84e8-c8fd69013d65
- Joined
- Sep 25, 2012
- Messages
- 28,368
Koa tua
- Joined
- Oct 3, 2015
- Messages
- 11,908
"The ancient kuo-toa people once inhabited the shores and islands of the upper world, but as the race of mankind and its associate species grew more and more numerous and more powerful. the 'men-fish' were slowly driven to remote regions. Continual warfare upon these evil, human-sacrificing creatures threatened to exterminate the species, for a number of powerful beings were aiding their sworn enemies - mankind. Some kuo-toans sought refuge in sea caverns and secret subterranean waters, and while their fellows above were being slaughtered, these few prospered and developed new characteristics to match their lightless habitats. However, the seas contained other fierce and evil creatures with designs of their own, and the deepdwelling kuo-toans were eventually wiped out leaving only those in the underworld to carry on the species. These survivors were unknown to men, and mankind eventually forgot the men-fish entirely. Even the word goggler, a derisive term for their ichthyoid foes, lost its meaning to humans. But the kuo-toans remaining in their underworld places did not allow memory of the past to lapse - and woe to the hapless human who falls into the slimy clutches of the kuo-toans."
The term "goggler" should be available for use.
The term "goggler" should be available for use.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.