Windows DopeFish - The Big Launch

IGameArt

Member
1613638618630.png
DopeFish has been set FREE!!

DopeFish is the only full GML Doom/Heretic map loading system for GMS2.3+ (so far as I'm aware)



What does DopeFish do?
Before we talk about that, let's talk about wads! Wad is a file format created by iD Software in 1993 for DOOM, and stands for "where's all the data". It has sense been used in games like Heretic, Hexen, Strife, Hacx and more! A wad file contains all of the content that makes up a video game, sprites, textures, sound bytes, music, maps, and so on.

So what does DopeFish do again?
DF
reads these wad files, and interprets the data that they contain, the textures, sprites, maps, and so on. It takes this read data and constructs a 3D level and fills it with content, and quite efficiently.

So it loads Doom maps, why? I can't make money off of a game with Doom Maps!
That's right, you can't sell someone elses content without prior written consent, so don't even try it! But what you can do is use any of the well established wad editing tools that hundreds of thousands of Doom Modders have been using for years to quickly and easily create custom content of your own for your own 3D games, very easily!

Take this scene for example:


In just one afternoon I was able to build out this scene using a pretty cool, and free texture pack that I found built just for making maps in the wad format!

So I can use DopeFish to make my own Doom like FPS?
Yes! But you'll be able to do so much more! DF is not a source port, it's not beholden to the gameplay of the boomer shooters of yesteryore, you are not bound by creed to create only a doomlike clone using DF. Why not a third person action RPG, a racing game, a moody walking simulator?

DF will ship with a handful of example levels and gameplay controllers to get you started on the way to crafting your own 3D game quickly and easily.

1651914916332.png
Okay, now that's all out of the way, let's get up to date with the current state of DF.

*May - 07 - 2022
  • Improved texture filtering. New texel space antialiasing shader improves texture quality at low screen resolutions for a smoother look.
  • wadLab is now available to download. You can finally test any fully self contained wads! ( DopeFish only works with single wads, so you can't load a list of wads and have them all work together, yet ).
  • Decorate scripting is now a thing! You can define new things in the decorate scripting language and have them call scripts that you've set up in your project to define all sorts of cool thing behaviors!
  • DopeFish source code is now public on github: https://github.com/Igameart/DopeFishEngine (Keep in mind, it's probably a mess, and definitely not production ready!)
To Do For Release
  • Add overrides for Things, Textures, and Sprites ( replace any texture in the map with your own, or replace any enemy with whichever object you choose )
  • Improve collision
  • Implement multiple example game type controllers
  • Mapdef, Animdef - define the environment of each map in your wad, and texture animations
  • Implement external info lumps: Define animated textures, switch behaviors, level layouts, and more


Possible Future Features:
  • 3D floors (rooms over rooms)
  • Sloped floors/ceilings
  • Geometry Normals
  • Dynamic Lighting/Shadows
 

Attachments

Last edited:

IGameArt

Member
Just spent the entire day implementing proper texture alignments. This is a huge deal for me and marks the final thing I've had to implement to get level geometry looking EXACTLY as it does in the classic games.

As a comparison this is what Hexen looked like before:


And this is what that same scene looks like now, with the addition of proper texture alignment and map things:
upload_2019-11-28_7-11-7.png

I am very happy with the progress I'm making on this!


Feel free to leave any feedback, comments, suggestions, questions, feature requests, whatever! :)
 

Joe Ellis

Member
It looks really good, I used to love making levels with build (duke3d level editor that came with the atomic edition) and I'd love to be able to make levels in that or a doom editor and use them in gamemaker \ convert them to a model. You've inspired me to start making a converter like this

I have a few suggestions that are mainly to do with taking advantage of the gpu and pc's being alot more powerful now,

If you're not already, I recommend building the level geometry into vertex buffers.

If you packed the textures used by the level onto a single texture, you'd be able to just have 1 vertex buffer for the entire level.
You could make a shader that repeats the texture tiles, by writing the tile index (x & y) to each vertex and use a uniform for the tile resolution\number of tiles per row & column to make the uvs wrap around that tile. eg. vec2 uv = v_tile_index + fract(v_texcoord) * tile_res;

I worked out a trick a month or 2 ago for eliminating overdraw by prerendering everything to the depth buffer but not draw anything to the pixel colors,
so when you draw everything properly it already has the depth of the nearest surface in the depth buffer and doesn't have to process any of the pixels behind it, which saves millions of texture reads, and this would probably be the same as the bsp performance wise, or could be even better because of less going on in the cpu.

The blockmap could be made at a higher resolution, which would be better for performance as long as you don't mind it taking up about 5mb in ram. And you could generate this during the loading sequence and not bother loading the info from the wad.

I noticed that when you look down, sprites are only using the view's yaw, if they use the pitch aswell they look the same as they do in doom and stops them looking flat.

For the "things", you could make a kind of map that links doom thing types to specific gamemaker objects. That could make it better for making levels in a doom editor and being able to place the enemies and stuff in there and it would play in gm without any extra configuration outside the doom editor, besides coding the actual objects.
You could do that with a single list if you made constants for the thing types, like:
thing_object[_type.mancubus] = obj_mancubus


But yeah, really impressive stuff so far! I hope it all goes well
 

IGameArt

Member
Thanks for all the tips Joe! A few of your suggestions are currently on my to do list. I plan on including some scripts to allow the end user to define whichever objects they want to represent things on a map, as well as overriding any textures used in a map. This way you can set up complex materials or swap in an HD texture or whatever.

A lot of people are commenting about how I'm using billboards that only rotate to match the camera yaw. But this is an intentional choice. Things in the map are meant to appear as though they are standing on the ground or hanging from the ceiling. If you rotate along the X and the Z, and look down, suddenly that enemy you've been shooting is laying flat on the ground, which looks so incredibly weird.

That might be suitable for some things but this just looks weird. The only actual "solution" to the issue is to use a 3d model or a voxel or something.

I've also been thinking about packing the textures to reduce the number of swaps each frame. But baking the whole level into a single vertex buffer probably won't happen because of how many different uniforms have to be passed into the shader for each sub sector for them to display properly.

I like your idea about using a depth pass to reduce the number of texture reads, but I think that may not be possible if I want to retain platform independence with this asset. I'm hoping to get this working for every export module. I know I could probably write different shaders and scripts for each module, but if I have to hard code something to get good performance out of mobile, may as well just use that for all platforms lol.

Anywho, thanks for all of the suggestions like I mentioned. You've given me some extra things to consider moving forward!


EDIT: Working on the Deimos Testbed interface. The theme will change to match the game that you have selected, this is the Heretic theme. This is how I'll be testing out the engine.

upload_2019-11-28_21-3-56.png
upload_2019-11-29_3-24-50.png

The testbed will be available for download from my patreon once I have that up and running.
 
Last edited:

IGameArt

Member
Working on the proper integration of doors.
Prior to this update the height a door would open/close to/from would just be defaulted to 64 map units. This update marks the first time since development began that the height a door would open too was actually dependent upon nearby ceilings. Now the door's will open to 4 map units lower than the lowest adjacent ceiling height, just like it is in Doom 1993 and all other games based on the engine.



The next step in this process is getting the speed of the open/close to an accurate representation.
 

IGameArt

Member
I'm not working on a source port MaGicBush. I'm creating a way for GM users to easily integrate complex 3d level design into their games using a widely available mapping format. I'm sorry that the idea of a patreon makes you lose interest in this project, but I am currently in the negative and damn close to being homeless at the moment. Just looking for a way to help keep food on my plate while I work on this.
 
M

Misty

Guest
Its sad but people really seem so delusional these days. Gamers will quickly hand over 60 dollars to any AAA company, but if a struggling indie dev just wants an honest wage for their work all of a sudden indie dev gets shamed, gets told they are a mercenary (as if that's somehow a bad thing?), and told they ought to work for free.

IGameArt, I hope that you do not become homeless, it is always a shame when great-coders come upon hard times.
 

IGameArt

Member
Thanks a bunch Misty!

Now back on topic, I managed to make some good strides and have doors and switches working, with sound effects also being played straight from the wad file!

 

TheSnidr

Heavy metal viking dentist
GMC Elder
This project is so amazing! Will pay attention for that Patreon. What you have already is something I've not seen done in GM before.
 

IGameArt

Member
Thanks @TheSnidr That really means a lot coming from you. I really enjoy pushing the bounds of what's possible in GM, much like yourself.

I think you'll probably notice, also, that I changed the name of the thread, and also the engine. Deimos is cool I guess, but I didn't have much attachment to the name and I think you'll agree the new one is much better:
 

IGameArt

Member
I've gotten a lot of really strong feedback on the change from Deimos to DopeFish, so I decided to go back to the drawing board and try making a new Deimos logo, what are your thoughts?
 

Yal

🐧 *penguin noises*
GMC Elder
This project is amazing, one of GM's flaws is lacking a good 3D level editor... and being able to use all the tools available for Doom is an oddly fitting choice, given GM's raw limited 3D access and how one of the official tutorials stole Doom sprites for years :p
 

IGameArt

Member
Haha yeah I remember completely butchering that code and getting it to produce results like this:
GlitzandGizmosscreenshot15035.JPG Glitzandgizmosshot4.JPG

Anywho, back on topic. I've gotten a lot of feedback on the new logo lately so I figured I'd take a stab at doing some more concepts.

 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
Screenshots are cool and all, but how does it look on the GM IDE side? Considering your previous history, I'd like to see some proof that your asset exists and works. You could've just taken those screenshots in ZDoom or Doom Builder and slapped a Dopefish logo and a GM window border on them to make them seem more legit. Especially since you missed the window border on one of the screenshots:
upload_2019-12-14_17-40-41.png

Also, the logo is different sizes on different screenshots, which further suggests it's been added on in post instead of being drawn by the engine itself. On the "17.57" screenshot it's blurry and antialiased while the WAD data is clearly drawn with interpolation turned off.
upload_2019-12-14_17-41-48.png upload_2019-12-14_17-42-2.png

Considering about half the updates so far are about the logo design and there's very little info about the asset itself, I'm worried about your priorities.


You even used the same "homeless" defense in that 2016 post. Maybe you should've considered FrostyCat's life advice about selling incomplete assets not being the best way to stay off the streets.
I'm not intentionally keeping my assets unupdated. I'm currently homeless right now and don't get a lot of time to spend on the computer. I'm trying to push my assets to build up enough revenue so that I can afford to keep updating them. I'm sorry to go so long between updates, I just can't afford to update them that frequently right now.
 
D

Deleted member 16767

Guest
He just got other priorities some times I guess but he really does seem desperate for money. If you're selling your product that means you will be getting customers that are genuinely interested in your product. And it's very stressing because when they pay you they have the rights to talk to you as if you are their customer support, because you are indie, right? Doing the project is fun, but managing it as a business is another. People doing a paid early access program really likes risking it. I'm just doing programming for fun nowadays. I had a game up on Steam that was a risky hobby but I'm glad I took it down before the money flew down the river, and the people were (not that many bought it actually) were refunded. But it's not like you're making a game where you toss some $$$ here and there, that's another self guilt you're looking at. I'm just telling you this now so you won't hit yourself later on. Better get that thing completed before you ask for money for an unfinished project.

And btw, does this just load doom maps? Why would someone emulate doom when 15 other people might do that too, and for what reason?
 

IGameArt

Member
@mikix This isn't an asset just for loading Doom maps. The goal of this project is to give GM users another tool to create their own 3d levels easily. Making custom doom maps is really easy to do, and when this tool is complete making 3d levels for GM will be just as easy to do.

@Yal I'm really discouraged by your post. I don't know what it is you're trying to prove by making such a post, especially after urging one of my potential customers to purchase your asset instead of mine on my own itch.io page.

Let's break down each of the points in your post starting with the proof that you'd like to see that this is actually written in GM.
First of all I'm flattered that you think this is incredible enough to try to disprove. However, have you noticed while taking samples from my screenshots that the larger Logo was above a scene that had a low resolution, low color depth, retro dithery look? This is another asset of mine, an older version of which is on the marketplace called RetroFexx. This asset alters the size of the gui layer, making text, or logos, appear larger than they would otherwise as it effectively lowers the "resolution" of the game screen.

The screenshots that are taken without a window border were actually captured when the engine was running in full screen mode. You'll notice that the resolution of those pngs are 1920x1080 (while the game resolution of 1280x720 is blown up to fill the png since I don't have dynamic resolution scaling active in this system at all).

Considering about half the updates so far are about the logo design and there's very little info about the asset itself, I'm worried about your priorities.
There's great reason for this. The original version of this asset was announced in 2016, back then it was called something different, it had the word yoyo in the title. I was naive in thinking that would have been okay but was told by a Yoyo Games rep that I had to change the name or remove the asset from the marketplace. It was around that time I essentially decided to put the project on hold as I had a lot going on in my life at the time and a recent update to GM actually broke a portion of the engine. Now that I have a little more free time as the game I've been working on for the past year+ is nearing completion I thought maybe I could mess around with that old code of mine and get it working in GMS2. So I did after a couple of weeks of messing around with the code off and on. After the recourse I got from the assets original name, you can see why I might want to put a good deal of focus onto crafting a different one. Being an artist and programmer I will often bounce back and forth from coding and art as a way to keep from burning myself out, which is important right now because I'm coding about 50 hours a week right now.

how does it look on the GM IDE side? Considering your previous history, I'd like to see some proof that your asset exists and works.
There's already proof of this above, but I'll go ahead and show you again.




You can see when the wad is loaded that it sends debug messages to the GM output window. It's more work to fake that than it's worth. If I wanted to make money with video editing I'd go get a job editing videos.

If this gif isn't good enough proof, here's a higher resolution video for you:
And in this link you can watch the original project's progress from inception to full level geometry, all done in GMS1, again, would be far too time consuming to fake than it would be worth. Especially when you consider this project has only made me about 30 dollars over the course of its development.

I don't post much information here on the forums lately after finding out that somebody has been urging people not to support me here. It's really disheartening to work so hard on something for someone to try and discredit when all I want to do is to see this community have a powerful new tool at their disposal. It hurts to know that people think I'm trying to pull a scam.

I think I've provided enough proof to the contrary. If you still don't support the work that I'm doing, that's fine. I can't please everyone, and trying to do so will cause me more stress than it's worth.

On a more positive note, I managed to fix an issue where some textures were missing in larger wads. In previous builds this grassy area would just show up as solid white, and really confused me. I tracked the problem down and it turns out I was limiting the engine to only checking for floor textures between f1_start/f2_start and f1_end/f2_end. Turns out some wads have flat textures in f3_start/end or higher.
 
Last edited:

Joe Ellis

Member
Yal's comment was really negative and disrespectful. I would not be discouraged by that. You've done a HUGE thing. Now you're polishing it and making it as good as possible. Well done :)
 

IGameArt

Member
Thanks @Joe Ellis. I'm working hard to try and create something special here, and part of my sharing this process is also sharing the issues that I have with this engine and my steps towards correcting them.

Along those same lines, I actually managed to fix an issue that's been bugging me for a while:


We're just going to call this issue midtex overlap. Essentially that grate pattern there is really only supposed to cover up the large open space in that wall. Clearly that's not happening here. What is happening is that the top and bottom level of the midtex is created by using the respective ceiling and floor heights of the outer facing side, basically making it as tall as the outer wall section. This is "normally" the correct way to do this. In fact the wall segments to the left and right of this midtex are also midtexes scaled the same way.

So my solution for this problem was to create a check for a back side. If this midtex has a backside, then the top and bottom of the midtex would be equal to the ceiling and floor of the room, or "sector" on the backside of the midtex.
This was very clearly the correct course of action:


I'm really pleased with this, and as far as I can tell, level geometry generation should now be essentially complete for the classic Doom/Heretic/Hexen formats!

The next steps are do some more research and get the node renderer working. This will only draw geometry that's actually visible from the location of the DEcam object. DEcam is a glovalvar that you can assign to any object in your game that acts as a camera.

Hopefully if this goes well we will see a massive improvement in the performance.

EDIT: Here's a look at the main reason behind me making this system. This is a map that I made using some custom textures I downloaded from the web.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
@IGameArt I owe you an apology. This framework just seems too good to be true, so I just assumed it couldn't possibly be real (especially with the scam concerns in the previous topic). And once I started getting suspicious, all the inconsistent details just stood out more and more. But with all this overwhelming proof of the project's genuinity, I can't doubt your intentions anymore even if I wanted. I'm genuinely sorry about my immature behavior, and I will try to practice the whole "giving people the benefit of the doubt" thing more in the future.
 

IGameArt

Member
@IGameArt I owe you an apology. This framework just seems too good to be true, so I just assumed it couldn't possibly be real (especially with the scam concerns in the previous topic). And once I started getting suspicious, all the inconsistent details just stood out more and more. But with all this overwhelming proof of the project's genuinity, I can't doubt your intentions anymore even if I wanted. I'm genuinely sorry about my immature behavior, and I will try to practice the whole "giving people the benefit of the doubt" thing more in the future.
I appreciate you saying that. Honestly an asset like this would work really well alongside your fps engine :)

I've been putting more work into this map, testing out various features of the engine in the process and making sure that the geometry is being generated properly. Doing this has allowed me to get things like fences to work properly, and to resolve more texture alignment issues. Here are a couple shots of what I'm calling Cruor Citadel. ( Cruor being the name given to the coagulated lumps in a blood clot )




You'll notice in this screenshot that there is an issue with seams still for some textures, namely the cliff face on the left and right sides of the castle. This is either a texture generation missing an entire row of pixels, or improper tiling. Either way I'll get this sorted shortly :p
 

Yal

🐧 *penguin noises*
GMC Elder
This is either a texture generation missing an entire row of pixels, or improper tiling.
There's a bunch of quirks in GM's 3D that could explain it, like textures needing to be a power of 2 along each axis... if not, they will be upscaled to the nearest larger size and random garbage color data will fill whatever's in the new space. So if that texture is 64x63 for some reason, it could explain it (all the affected polys seem to use the same texture). Would've suggested interpolation issues as well, but the image is clearly drawn with interpolation off. (There's a trick to deal with imprecisions in UVs involving not using 0 and 1 for texture coordinates at the very edges of a texture, but rather 0.001 and 0.999, but I think that shouldn't cause issues when interpolation is turned off)
 

IGameArt

Member
Many of the textures loaded from a wad contain 1 side that's not a power of two. I'm currently using sprite_get_uvs() to determine where on the generated texture page the edges of the sprite lie to try and prevent weird seams like this, and it's working in almost all circumstances, which lead me to believe that this could very well be an issue with the texture itself missing a row of pixels.

EDIT: I'm also contemplating the merits of adding loaded textures to a large atlas to reduce the number of texture swaps.
 
G

Galladhan

Guest
This framework just seems too good to be true, so I just assumed it couldn't possibly be real (especially with the scam concerns in the previous topic).
I have to confess that i felt very skeptical too when i discovered this project, cause in the past i bought 2 assets from the OP (Structerra and BLOKZplus) "with the promise of frequent updates" and then they disappeared from the Marketplace after little time and zero updates. That was disheartening too, believe me @IGameArt, especially considering they were the first assets i bought on the MP...

But! I wouldn't be fair if i didn't recognize that this time your attitude seems totally different: you're not promising anything, and you're stating clearly that you need support in order to "afford you the ability to continue developing the system".

I have to hand it to you, man, i appreciate it. And i'm ready to forget about the past and maybe even to support you again. Talking about this, i would like to ask you a couple of questions: if you shouldn't manage to raise enough funds, the supporters would still get the current update of the file? Or maybe a refund?
If you get good support, instead, how long do you think it could take before you can publish the project?
I mean, i know it's difficult to predict, but... we're talking about weeks or months? Just to have an idea. Thank you!
 

IGameArt

Member
Both Structerra and Blokzplus were completely destroyed by a GM update that rendered them completely useless. I'm not sure what that was but I was unable to fix it at the time, which is what ultimately lead to them being pulled from the marketplace.

I plan to continue developing this system regardless of whether or not it turns any kind of profit. Luckily soon I'll be releasing a major commercial game that will "hopefully" contribute greatly to solving the money issues i've been facing. Especially once we release on the Switch. However if after some time any of my supporters decide they've waited too long and decide to ask for a refund, should I have the cash on hand, I'm not opposed to issuing a refund.

As far as how long until I release a usable asset, I'm honestly not sure. If I don't have almost all of the features of the Doom1/2 mapping system implemented then this asset is basically useless, and there are a LOT of features I need to implement. This is in part why I've created the Wad Lab, to give people a chance to see the engine in action without first putting broken code into their projects. I can say that it will likely be a few months of development before the first version of DopeFish is released for use. And then after that a few more months for more modules to be added to the system.
 

Jase217

Member
Hey IGameArt! This is great and will definitely be useful for people making sector based 3D games in Gamemaker. As someone who's had to make my own 3D level editor for my game I know how tricky that can be, this is something I'll definitely check out when it's ready. I was wondering, does your engine support mipmapping on those external textures?
 

IGameArt

Member
Yep, mipmapping works perfectly fine on generated textures. Here's a screenshot where you can see it in action. Most noticeably on the gray gravel.

 

CMAllen

Member
Both Structerra and Blokzplus were completely destroyed by a GM update that rendered them completely useless. I'm not sure what that was but I was unable to fix it at the time, which is what ultimately lead to them being pulled from the marketplace.

I plan to continue developing this system regardless of whether or not it turns any kind of profit. Luckily soon I'll be releasing a major commercial game that will "hopefully" contribute greatly to solving the money issues i've been facing. Especially once we release on the Switch. However if after some time any of my supporters decide they've waited too long and decide to ask for a refund, should I have the cash on hand, I'm not opposed to issuing a refund.

As far as how long until I release a usable asset, I'm honestly not sure. If I don't have almost all of the features of the Doom1/2 mapping system implemented then this asset is basically useless, and there are a LOT of features I need to implement. This is in part why I've created the Wad Lab, to give people a chance to see the engine in action without first putting broken code into their projects. I can say that it will likely be a few months of development before the first version of DopeFish is released for use. And then after that a few more months for more modules to be added to the system.
I'm given to understand those weren't the only projects broken by some kind of 'under the hood' update. There's a 2d skeletal animation project right here on the forums suffering a similar fate because of an undocumented (and unnecessary) change to an important function.
 

IGameArt

Member
I'll try to keep this update fairly short but there's quite a bit to go over :)

A lot of effort has been put into what's referred to as the two sided middle texture. Let's take a look at this example:

As you can see walls are generally made up of three textures, Upper, Middle, and Lower. In most cases only the middle texture will be visible, for walls that are designated as 1-sided. This version of the middle texture is pretty straight forward and quite easy to parse. However the Middle Texture that lies on a two sided wall is far more complex. In this case, the middle texture does not repeat vertically in traditional doom map formats. In fact the geometry for a two sided middle texture will sometimes not even extend the full height of the wall, and setting the vertical offsets for this texture will actually change the location of the geometry on a wall segment, much like the fence in this image:



This is something that we've now implemented into Dopefish. In previous updates middle textures were, well, broken:



Compare that to how it's actually supposed to look:



So you can see things are looking pretty great for the level generator itself, now let's take a look at some of the other texture related changes to the engine.

In order to test out the features of DopeFish while adding them to the engine, it was important to me that I began creating a custom map as a showcase of what the engine could do. So I downloaded the OTEX.wad texture pack that was used in the construction of the great megawad
Eviternity. After fiddling around for a couple of hours I managed to have the start of a pretty cool looking blood castle:




This is great! Except.... what's that seam on the cliff face? The heck? Turns out that's not a problem with Dopefish! This is actually showcasing a limitation of the original doom engine. Texture patches can't exceed a height of 254 pixels, and that texture there is 256 pixels. I can't tell you how long I messed around with the map, and the engine code until I stumbled upon the solution while doing an internet search. This texture pack has what they call Boom compatibility. This means there are features in this texture pack that are not supported by the original Doom source port, in this case, DeePsea Tall Patches. This is a method for storing larger textures in the wad format without having to actually change the format at all. You just have to change how you read the format. After a few hours of trying to decipher the format I finally finished implementing the Tall Patches feature. Now DopeFish can load textures as tall as you can imagine, just look at this, that chain texture there is hundreds of pixels tall and wide (it's currently cropped to fit smaller geometry) and it's working just fine! And no more seams too!



And finally the last thing i want to glance over really quickly is middle texture alignment. Let's take a look at this section of the castle interior that I built:



You can tell something weird is happening here, those skull textures are completely misaligned. There's reason for that. You see middle texture alignment can be an odd thing because sometimes the height of the wall actually extends far beyond the height of the ceiling, as evident in this image here taken from the map editor I was using:



Here you can see that the textures are aligned properly, in fact the top of these textures is perfectly aligned to the height of the ceiling. This means that I needed to change my code to shift the textures downward by the amount of world units that separate the height of the wall from the height of the ceiling. And with that, we finally have excellent texture alignment. Here, have some more screenshots and whatnot!



 

z_bill

Member
Hi! I made an account here just to let you know you are my hero for making this!

This is exactly what I need to really get going with a first person 3d game in GMS2! Please keep it up (and please don't tell me production has halted! Haha)!

Is it progressing ok? Really, for my purposes, I just need the maps (sectors, walls, linedefs) to be working/importable, and not as much items or enemies (any of the billboard sprite content, as I'll create my own method) or HUD info/art. Basically, as a quick way to bang out levels, this would be an absolutely amazing tool!

Thanks!
 

Yal

🐧 *penguin noises*
GMC Elder
Yeah, I'm also curious how things are going after the sudden several updates per week --> no info for a month activity drop... Even if you're having bugs and issues to work out, they still make for pretty fun status updates (especially when something bugs out in major or amusing ways).
 

IGameArt

Member
Thanks for the interest folks. I've been working on the optimization side of things lately, but have had to take a short break to put some more energy into my game as we are getting closer to our desired release date. I've managed to get the BSP traversal implemented to properly sort all of the level geometry, but the next step is to implement the culling of geometry that's not visible from the camera location. This part is proving a bit trickier than I'd like it to be.

Hi! I made an account here just to let you know you are my hero for making this!

This is exactly what I need to really get going with a first person 3d game in GMS2! Please keep it up (and please don't tell me production has halted! Haha)!

Is it progressing ok? Really, for my purposes, I just need the maps (sectors, walls, linedefs) to be working/importable, and not as much items or enemies (any of the billboard sprite content, as I'll create my own method) or HUD info/art. Basically, as a quick way to bang out levels, this would be an absolutely amazing tool!

Thanks!
This is pretty much exactly what this has been designed for, getting levels into GM rapidly. Progress on this project is a little slowed down at the moment as I'm bouncing between dayjobs and hobbies right now, but your enthusiasm for the project is really motivating.
 
Last edited:

Joe Ellis

Member
This is definitely a really useful tool for converting doom levels into models. Sector based editors are amazing and probably still the easiest way to map 3d levels out.

I was wondering, does the geometry end up being built into vertex buffers? Cus then you could easily make a doom level to obj converter.
I think loads of people would like to use a doom level editor to make the initial layout of a level, then convert it to a 3d model and edit it further with the stuff that the doom engine can't do
 
Last edited:

IGameArt

Member
That's usually not super good for performance compared to a single huge vertex buffer, just so you're aware :p
The main reason for the break is that each texture is separate, rather than saved to an atlas. At least for the time being. I'm still experimenting with optimization methods though
 

z_bill

Member
Bumping this thread, cuz I'm kinda giddy about how awesome this tool would be. I've got a really cool game idea already!

One thing I think would absolutely ace is making a "Doom mod," like get a bunch of Doom mappers collaborating on Doomworld to make cool levels for a WAD that is converted to GMS2. For a game that plays nothing at all like Doom!

The collaboration potential of this is sorta out-of-control, everyone can make a Doom map!
 

Jase217

Member
The main reason for the break is that each texture is separate, rather than saved to an atlas. At least for the time being. I'm still experimenting with optimization methods though
Just a heads up I've tried repeating a texture from an atlas for batching reasons, it's all fun and games until you try to get mipmapping to work with it. It'll create seams at the borders of each repeat, and GM seems to be missing certain GLSL shader functions that would solve this like the textureGrad function. Not sure why that is.
 
Top