Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
bonnie

Doom in Swift

Recommended Posts

hello

i wish to embark on a journey

a programming journey, specifically

 

edit {

I'm basically just stealing a 64-bit fork and adding virtually nothing to it. I just need the assets, like base.ipack and whatnot, from either gameception or the original app (not including doom.wad obviously) got them but now it just crashes at the splash screen with no errors, oof

}

  1. Has it been done before?
  2. If not, is it possible?
    • Like realistically possible, for someone with only basic knowledge of Swift
  3. How long should this take? I can sink a lot of time into this if I need to.
  4. What resources should I use (like source codes, websites, guides, helpful thingies)?
  5. What compatibility should I aim for? (i'm guessing boom)
    • Would it make sense to aim for vanilla doom and then port it to boom? or is that too much work?
  6. Are there any really really important, however obvious, issues that I may run into?
    • How should I address them????
    • Like stuff about C, stuff about how things work i might not realize, stuff about stuff
  7. do you believe in me? ;~;

 

 

My main goals are things like:

  • full IWAD support (done?)
  • pwad support (is there code for this in doom classic's source?)
  • dehacked support (still possible?)
  • boom support (done technically, right?)
  • browser for downloading wads and stuff (like gameception but more refined and accessible)
  • controller support (something gameception lacks)
  • simple multiplayer, possibly using local bluetooth

 

i may or may not pursue actually getting this onto the appstore. obviously it would be possible, since gameception got away with it, and it kinda needs a 64-bit version anyways. i really just want to do this... well, for fun. i like doom. it'll be fun and will drastically improve my programming skills if i can pull it off c:

 

i just need a little loving nudge in the right direction

i'll post updates and further questions in this thread if applicable

 

love,

bonnie

Edited by bonnie : gave up trying to be innovative or interesting

Share this post


Link to post

It hasn't been done before. Of course it is possible, but it's going to require anyone taking the venture to create bindings for some critical pieces like SDL -- I did a cursory glance and it seems nobody has done that before. Swift isn't a popular/big language, and its origins as primarily being for iOS doesn't help that (Apple currently only supports it for Mac, iOS, and Linux). Basically you're looking at binding SDL APIs to Swift, which may or may not take extremely long (depends on if Swift supports the C ABI), plus rewriting the game in a new programming language. There's no way around that, you don't simply port C to Swift, it's going to be almost a complete rewrite.

 

If you are up for a challenge, go for it, but I think you need to ask exactly what your goal is. It sounds like you are fairly inexperienced at programming; perhaps hacking on an existing source port with only C (or C++) is the better route?

Share this post


Link to post
15 minutes ago, chungy said:

(Apple currently only supports it for Mac, iOS, and Linux).

i probably should have mentioned that this was gonna be for ios

 

now, i have no idea what any of the other things you said meant, but i can tell you that i've got a can-do attitude and a passion for learning

 

also it's very important that i use specifically swift

and i guess if i had to lay out one specific doom-goal, it would be iwad/pwad boom support

and also you really spooked me with that SDL thing like heck, please talk in simpler terms

also also how long is "extremely long"

edit: if i worked on this for at least 4 hours a day everyday for the next month, would I complete it?

 

but thank you for your deeply discouraging words friend ;~;

 

edit: are either of these links related to that binding thing you were talking about?

https://github.com/jaz303/SDL2.swift

https://github.com/PureSwift/SDL

Edited by bonnie

Share this post


Link to post
1 hour ago, chungy said:

It hasn't been done before. Of course it is possible, but it's going to require anyone taking the venture to create bindings for some critical pieces like SDL -- I did a cursory glance and it seems nobody has done that before. Swift isn't a popular/big language, and its origins as primarily being for iOS doesn't help that (Apple currently only supports it for Mac, iOS, and Linux). Basically you're looking at binding SDL APIs to Swift, which may or may not take extremely long (depends on if Swift supports the C ABI), plus rewriting the game in a new programming language. There's no way around that, you don't simply port C to Swift, it's going to be almost a complete rewrite.

Are you certain? Last time I used Swift with C, binding C to Swift was automatic (albeit with inconveniently verbose UnsafeMutablePointer<...> stuff for raw pointers). C is simple enough and Swift has support for unsafe stuff. Thus SDL may work directly with Swift clients. This also means that you can gradually replace C code from Doom with Swift code, and not entirely at once. I hope Swift didn't change for the worse in this respect.

 

I'd only do that if I could refactor it into cleaner code taking advantage of Swift's OOP/functional syntax, and only to high-level stuff such as playsim. The rendering stuff looks like low-level style to me.

 

@bonnie

A Doom port running on SDL2 should compile and run as-is on iOS. No need to change C language to Swift unless this is your goal. You'll need to add a touchscreen user interface however.

Edited by printz

Share this post


Link to post
4 hours ago, printz said:

A Doom port running on SDL2 should compile and run as-is on iOS. No need to change C language to Swift unless this is your goal.

so i don't have to do that scary binding thing?? i just want to make the doom engine in swift, i'm fine with keeping the SDL2 thingy in C if that will help me

 

is there anything else i would need to know about using or incorporating SDL2 or something? are those links i posted in my other post relevant or helpful at all?

 

i also want to ask again: if i put at least 4 hours of work a day everyday for the next 30 days, do you think i'll be able to finish this? with all my goals and stuff

 

also also would dehacked support be feasible to implement or should i just abandon that part early?

 

thank you so much friend

Share this post


Link to post

I want to say this in the kindest way, and I don't want you to get disheartened: from what you've said I don't think you have the skills yet to do this project.

 

That doesn't mean you'll never be able to do it, and it also doesn't mean you wouldn't be perfectly capable of doing a different project instead. But you need to learn to walk before you run.

 

Think of it this way: suppose you went to a piano teacher and said, "I know how to play Chopsticks, but I really like this Mozart guy - how do I play his stuff?". Everyone knows that playing a musical instrument, or learning to draw or paint (for example), are skills which take time to develop, and programming is the same.

 

To be clear you seem to be trying to do several difficult things all at once:

  • Porting code to a different operating system
  • Translating code to a different programming language
  • Reverse engineering / understanding a large code base (the Doom source code)
  • Learning to program / learning Swift / learning its APIs

I'd suggest you instead pick a more modest project that requires a similar set of skills. For example: it's probably a reasonable goal to make a basic iOS/Swift Doom level editor. See if you can manage that, and if you do so you'll develop a lot of the most important skills you need for a more ambitious project like a Doom source port.

Share this post


Link to post
9 hours ago, bonnie said:

Would it make sense to aim for vanilla doom and then port it to boom? or is that too much work?

Ask Maes about his experience porting vanilla to Java to make Mocha Doom.

Share this post


Link to post
1 hour ago, fraggle said:

it's probably a reasonable goal to make a basic iOS/Swift Doom level editor.

but that sounds hard and kinda impractical... i mean, it would be pretty cool and slightly useful, but i really don't know if i can (but somehow i think i can port all of doom)

 

what parts of doom specifically would be the hardest to port? i might initially try for something like nasty, where you can load assets and what around, but there's no gameplay or anything

 

then if i can somehow pull off the actual rendering stuff and whatnot, i could try adding bits and pieces of the other stuffs

 

maybe i don't have to directly translate doom's source code to swift. would it be any easier to just hack together something that could run doom, like that c++ one? even if it meant sacrificing compatibility for most wads, i'd be willing to make that trade

 

im not completely clueless, it's just that my knowledge is currently pretty narrow ;~;

 

i really don't wanna give up on this

please

Share this post


Link to post

Doom's source is really hard core old-school C. Meaning, it uses coding practices that are highly incompatible with modern programming languages and with modern programming techniques.

You will end up fighting at two fronts here:

 

- understanding the code as-is - it is not particularly intuitive what it does in places

- making this stuff work with another language that is designed for far more modern coding practices and simply does not allow some of the stuff Doom was able to get away with 25 years ago. And even if you manage, you still have to deal with the fact that the Doom code is full of side effects that may not be there anymore in your ported version.

 

A porting job like this will be a major task for an experienced programmer. Unless you honestly consider yourself one, I can assure you that you won't succeed.

 

Share this post


Link to post

If, despite these posts, you’re still determined to do it: do it! Don’t forget to keep us posted on your progress.

Share this post


Link to post
Quote

then if i can somehow pull off the actual rendering stuff and whatnot, i could try adding bits and pieces of the other stuffs

You gloss over this like it's simple, but it's no trivial matter.

 

47 minutes ago, bonnie said:

but [writing an editor] sounds hard and kinda impractical... i mean, it would be pretty cool and slightly useful, but i really don't know if i can (but somehow i think i can port all of doom)

Trust me when I say that it would be an order of magnitude simpler than what you're proposing.

 

The most important thing is that you should find yourself a project that you can break down into a number of sub-goals, so that you can have some successes which give you confidence to keep going and building further on what you've already achieved. That's very hard when the goal is "port an entire unfamiliar codebase to a different language and OS". I'm worried that you'll try to do too many things at once, fail, and it'll damage your confidence.

 

I suggested "make an editor" because it's a lot more straightforward to break down:

  • Write some Swift code that can read WAD files and list their contents
  • Make a basic level viewer that can draw all the linedefs and things in a level
  • Extend the level viewer so that you can move things around and save a modified WAD
  • Extend the editor so you can add and remove lines and sectors
  • Write some code to save these modified levels too
  • Find and port a BSP builder to iOS and/or Swift (gives you some experience working with other people's code, at a smaller scale)

It doesn't have to be "make an editor", it's just a suggestion. But something where you can set realistic sub-goals where after a couple of days you can step back and say, "Cool! I made a {thing}!" helps a lot.

Share this post


Link to post
13 hours ago, bonnie said:

i probably should have mentioned that this was gonna be for ios

Yeah, if it's exclusively iOS then you probably should ignore SDL and use whatever iOS provides. SDL's more for actual desktop operating systems.

 

Seriously though, maybe you should take the iPhone Doom source code and hack on it. Rewriting in a new language is unnecessary.

Share this post


Link to post

Fraggle's suggestions make a whole lot of sense. The editor suggestion is good too, because it directly affects your eventual goal:

Any Doom game needs to be able to understand the resources that an editor does. An editor requires being able to draw the game's images on the screen, and requires the program to be able to accept user input, which the eventual game also requires.

 

Please don't be insulted, but, from the wording of your posts, it doesn't seem like you've done much programming at all. You're going to have to master at least some basic concepts before tackling Doom. But, if you absolutely can't wait, and you are ambitious enough, there's another possible quicker route to get there:

 

I suggest download the source of one of the more simplistic Doom ports out there, and figure out how to compile it as-is (Make an executable file out of the source). Once you can do that, you can try to make one simple change to the code, and compile it again. Then see and try to totally understand exactly how that change affects gameplay. You can continue this process, and eventually gain some understandings.

 

To learn more, you can find resources all over the web, that help you understand more difficult concepts. After a few months, you might be surprised how much you've learned. And, you might hit a roadblock that prompts you to break down, and actually learn the entire language, in and out. But, you will already have a lot of knowledge, which will make the learning process that much simpler.

 

Four hours a day for a few months, on the PC, in the C language, using a working port's source, combined with studying the language, and you'll begin to be confident enough to make some meaningful changes to that port. Porting the code to another language, on different hardware, is a major task.

 

Baby steps - with many small, explicitly-stated goals that you can achieve, is the way to get there.

 

You ask "Do I believe in you?" I don't know you enough yet to answer that. But here's what I do know for sure: Like most skill-related things in life, programming is not for everyone. And, that's ok - I'm sure there's plenty of stuff that you can do a lot better than I can, for example. Programming requires extreme focus, and discipline. The computer *always* does exactly what it is told, and only what it is told. The secret is in knowing how to tell it what to do. If you get it wrong, it will not work until you get it right, and it doesn't care either way, regardless.

 

Having said that, if you have the ability to focus, the desire to learn, and the time to do so, you will eventually learn everything you need to know to accomplish this, and many other goals. And, best part, you'll create a career for yourself. But, if you're the type of person that tries a few times, then gets frustrated and quits, you'll never go very far. Because, again, the computer doesn't care, and the program will never work, until you tell it what to do properly.

 

You might find it interesting to keep a log of your progress. Maybe weekly, or monthly (I think it's going to take a lot longer than a month, no matter what your goals are.) I don't know how old you are, but this is a big decision, if you're going to see it through. I say take your time, and spent a lot of time learning the basics, as completely as you can. You can find everything you need to learn online.

 

But some things are only learned by trying. So study, but also write your own programs. Keep them very small and simple. Write a Tic-Tac-Toe game. MadLibs. Draw a small spaceship, and try to make it fly across the screen. Add a starfield. Make the stars move towards the screen, like you're flying through space, with a 3D view. These small goals are way more important than porting Doom, at first (and probably more interesting - you're making something all your own).

 

Please let us know how you're progressing. Good luck!

 

Share this post


Link to post
11 hours ago, bonnie said:

what parts of doom specifically would be the hardest to port?

Any of it. All of it. Think about it: You will have no screen output until you can:

  • learn how to draw graphics to the screen
  • load WAD files, interpret the WAD header, be able to search for lumps in the WAD by name
  • read individual lumps
  • interpret the Doom image format (dimensions, offsets, pixel columns)
  • load the PLAYPAL lump and store its RGB values
  • use the PLAYPAL data to convert the image lump pixels into RGB pixels
  • write those pixels to the screen

That's a few hundred lines of very specific code, and, you have enough code to show the TITLEPIC. No 3D rendering, no network, no demos, no music, no sound, no menu, not even any user input. It's going to take time, and Doom is WAY too big to start on. You can get there. But you have to be prepared to put in your time.

Share this post


Link to post

well since i'd apparently need to put 4 hours a day for several months just to be able to make changes to a port, i guess i need to abandon that idea entirely

 

making a map editor doesn't sound much easier either

 

im kinda hard pressed for time to try this, so are there any other possible doom related projects that i could attempt in swift (including the map editor if that would somehow be doable)? what does the world need right now?

 

and no, i'm not going to hack something together in C or "breakdown" and learn the entire C language. it's swift or nothing. i just wanted to do something fun and doom related in swift.

Edited by bonnie

Share this post


Link to post

Here's an idea: a Dehacked editor for iOS. You will open DEH and BEX files with it and edit them with text boxes and view stuff in image views and media players.

 

iOS provides the UIDocument class for editor apps.

 

The challenge here is parsing the DEH file. Just try it step by step until it works. Maybe Swift has parsing helpers in its SDK. Maybe there are actual grammar/parsing libraries you can download and use! 

 

 

Share this post


Link to post
1 hour ago, bonnie said:

making a map editor doesn't sound much easier either

It can be hard to judge the difficulty if you're still relatively new to coding. I think it's a lot more straightforward than you think, and I believe you can do this. Put in a month, do a bit every day and I think you'll be surprised what you can achieve. It might take you more than a month to put together a complete, fully-functional editor, but after a month you should definitely have something to show for it.

 

1 hour ago, bonnie said:

im kinda hard pressed for time to try this, so are there any other possible doom related projects that i could attempt in swift (including the map editor if that would somehow be doable)? what does the world need right now?

Don't worry too much about making something that other people need, make something that you enjoy, solve a problem you find interesting. Remember that this is a learning experience - the most important thing is that you learn something at the end of it.

Share this post


Link to post
1 hour ago, bonnie said:

it's swift or nothing.

 

Is there any reason for that? Don't think that this might give you any advantage when applying for an iOS programming job. Even there, larger projects depend a lot on external C and C++ libraries and programmers which cannot work on both sides are at a severe disadvantage, despite what Apple promotes.

You may not even get anywhere with Swift, because most older code bases are still Objective-C with no intent to port them to Swift ever.

 

However, if you want to learn Swift, start small. You cannot expect to develop some large and complex project right out of the gate. You first need to get a grasp on the system you want to develop for, and that's mostly done by studying and modifying existing examples and trying to understand why and how they work. Game development is one of the hardest tasks around. You may give a game developer almost any project and they'll be able to work on it, but give a run-of-the-mill corporate programmer the task to work on a game and most will fail because all the stuff that's so neat in such an environment just won't cut it for games. Mastering the Doom source can take, from what I heard, months to years, to merely get a basic understanding of its concepts. I always feel totally overwhelmed when just looking at the original vanilla source.

 

Share this post


Link to post
1 hour ago, Jerry.C said:

Is there any reason for that? Don't think that this might give you any advantage when applying for an iOS programming job.

This might shock you, but I'm not doing this to snag job oppurtunities as an iOS programmer.

 

I already know quite a bit of Swift, so I'd rather not waste time learning a new language when I really just want to make something in Swift for fun.

 

1 hour ago, printz said:

Here's an idea: a Dehacked editor for iOS.

that sounds a bit light though

a dehacked editor with only the text parts would feel really... incomplete

 

would making a mobile SLADE (without the map editor) be feasible though?

 

1 hour ago, fraggle said:

I think it's a lot more straightforward than you think

i certainly hope so because it sounds pretty complicated. i have absolutely no idea how i would even start something like that, and i feel like my resources will be more limited and harder to understand

 

and unless you're implying i make an editor with no form of 3d view, wouldn't i still need make code to be able to render doom environments, interpret map geometry, and do most of the things kb1 listed? at that point i'm gettin pretty heckin close to a source port

 

and all of the steps you listed earlier seemed pretty vague and not-so-straightforward themselves

 

i would like to make an editor, but i'd want to make one that's actually useful, but it seems to still require an immense amount of work... though i'm not entirely opposed to a map editor with no 3d view

Edited by bonnie

Share this post


Link to post
Quote

and all of the steps you listed earlier seemed pretty vague and not-so-straightforward themselves

I thought they ought to be reasonably clear. What can I do to make them more clear?

 

Quote

i would like to make an editor, but i'd want to make one that's actually useful, but it seems to still require an immense amount of work... though i'm not entirely opposed to a map editor with no 3d view

To be clear, I was just thinking of a basic 2D editor and wasn't even considering a 3D view. Back in the '90s none of the editors had 3D views and we got by, though I appreciate it can seem archaic nowadays. But it doesn't change the fact that you're not going to realistically do 3D before you do 2D. It's a good progression of the kind I've described: make a 2D level viewer first; now can you make a 2D level editor? Now can you make a 3D one? Can you grow that into a source port?

 

That said, I worry that you're getting too caught up in grandiose plans and trying to consider every potential problem before you even start. What's the smallest thing you can build now that would be a stepping stone towards something bigger? What small goal can you set for yourself today? Don't worry about every potential problem you might face down the road because you haven't got there yet, and you'll have learned a lot by the time it's really something you need to address.

Share this post


Link to post

For the editor approach, you can work incrementally. In fact you can just make a resource viewer in a first time.

 

  1. Make a very simple app that just displays some text. Your standard "Hello World" thing.
  2. Add to this a way to open a file. Then make it display something based on the file you've opened. Maybe just its size.
  3. Now write a parser/validator. When the file is opened, it'll check to see if it's a valid wad file. Then you can display its size, and the number of lumps it contains. To do that you'll have a function iterating over the lumps. Perhaps some other statistics if so you want, like whether it's an IWAD or PWAD, or how many maps it has. Make sure to handle it gracefully when people open something that's not a valid wad file.
  4. Now that you've got all that, add a list display, so that you can show all the lumps that the wad file contains. A big scrolling two-column display with name and size for each lump. You'll fill the data structure for that list display from your lump iterator.
  5. While you're iterating over them, identify which lumps are Doom graphics, Doom flats, or Doom sounds. Add a type column to your list display. So you'll have four types of lumps: graphics, flats, sounds, and others.
  6. Now is the time to start going in a bit deeper and figure out how to draw bitmaps and play sounds. So that when you tap a graphic lump, it'll display the graphic in a popup or something. When you tap a sound, it'll play it.
  7. If you want to go on, extend this for more lump types. Like handling MUS and MIDI.
  8. Now let's tackle maps. Make your app able to recognize and parse maps -- they're complex because they're more than a single lump. So you've got to validate the map by making sure it has all the lumps it needs, in the proper order, and that each lump is also valid for what it is supposed to be. For a first step, just gather stats, so that when you tap a map header, you'll get statistics about how many things, sectors, lines, etc. are in the map. Bonus point if you tackle subsectors, segments, and nodes, too.
  9. You've got all this infrastructure in place, so work on getting a 2D map view, based on the data you read from the map. You can start with just the basic geometry, then add things. Then add flat textures and thing sprites and light levels.
  10. Now that you have an application that can read wads, view maps, display Doom graphics, play Doom sounds, and possibly even play Doom music, you can decide the next step -- go full editor, or start turning your app into a game? In the latter case, you'll be able to start porting bits of the Doom (or PrBoom+) code and plug them in what you have, so you don't need to do all at once. Port the world rendering so that when you tap a map you can explore it. Perhaps just as a free-floating, no-clipping camera for a start. Once you can explore the levels, add player physics. Then start porting the real gameplay bit with weapons and monsters and stuff. Implement demo playback, level progression, this kind of things. Then menus and intermission and other stuff. Eventually you'll get a working port that grew out of a Hello World program.

Share this post


Link to post

alright, new plan

apparently i'm incapable of doing the things i desired and things i can do aren't particularly useful

 

since i've lost several days, i propose a (not) new idea: just take the ios doom source code, leave it in c if possible, attempt to update it, then add things to it in swift (basically gameception but hopefully slightly better)

 

not quite what i had in mind originally but it would still be fun for me

would this be possible and agreeable

 

my main goals would be:

- get it updated and working

- add pwad support

- ability to download custom wads and .zips

- simple multiplayer

- controller support

 

extras:

- option to remove texture filtering?

- revised menu, possibly using graphic lumps from the wads (possible?)

- that's really it, i would have to make up more things to do if i finished everything

Edited by bonnie

Share this post


Link to post
On 5/1/2018 at 12:24 PM, bonnie said:

This might shock you, but I'm not doing this to snag job oppurtunities as an iOS programmer.

 

I already know quite a bit of Swift, so I'd rather not waste time learning a new language when I really just want to make something in Swift for fun.

I am baffled by this statement. Learning C would help you learn Swift and all other languages. It's as if you want to run before learning to walk. Things are hard for you to understand because you don't have a grasp of the basics, apparently (no insult intended.) Learn C, and you'll understand the Doom source, which will let you understand how to load WADs, read lumps, draw and edit images, and even render 3d views. It will also let you understand all of Swift, because essentially all languages can be translated to C. C is essentially one step away from the language the computer actually runs, machine language.

 

I mean no insult, but in my opinion and experience, a real programmer learns constantly, and learn every language and technique possible, and never stops. If you really want to be able to build useful programs, you absolutely need to learn about data types, local, global, and static variables, arrays, structures, loops and other block statements, boolean logic, conditional statements, memory usage, objects, classes, handles, file handling, error trapping/exception handling, subroutines and functions for starters. And, yes, most all languages will support all of those constructs. And once you learn all of them proficiently in one language, that knowledge transfers into the learning into another language.

 

What I'm saying is: Learn your basics first. Write a few simple programs first, and read ALL of the commands and functions the language supports, and use each and every one of them, in simple programs. Learn to have fun learning. You don't have to publish everything for it to be useful. It's useful to you, if you learn something. I don't understand this need to make something useful for other people, when you're not ready. Get good first, then you can knock their socks off later. That's the best advice I can give, whether you do that in Swift, or C, or you learn both (which is better - there's a huge resource of C programs, not so much for Swift.)

 

I don't want to discourage you. But learning this stuff takes time. However these days you've got tons of resources a few clicks away, that I never had. Spend your time wisely and learn from the ground up, and you'll be able to make anything your heart desires. But if you jump the gun, it ain't gonna work, and you're going to get frustrated and give up.

Edited by kb1

Share this post


Link to post

Given how little time you’ve got, I don’t know why you’re wasting it arguing here. Like I said in my last comment, if you’re not dissuaded by what people have said, *go forth and code*!

 

Edit

 

18 hours ago, bonnie said:

alright, new plan

apparently i'm incapable of doing the things i desired and things i can do aren't particularly useful

 

since i've lost several days, i propose a (not) new idea: just take the ios doom source code, leave it in c if possible, attempt to update it, then add things to it in swift (basically gameception but hopefully slightly better)

 

This is a fine plan. Good luck

Edited by Jon

Share this post


Link to post

I'm really at a loss as to what the motivation for this is.

 

Like, you've made it abundantly clear that this is just something you want to do. Not something for the sake of a resume or portfolio, or even for the sake of learning how to better use the required skill, but just a flat-out passion project. But even though it's just a whim, there's a hard deadline on it?

 

I mean, setting deadlines for yourself is a good way to keep motivated, but that's still for stuff you have the intention of delivering soon. It's certainly not something just for the sake of doing it that you're not even certain if you can accomplish.

 

It really feels like something's not being said here.

Share this post


Link to post
4 hours ago, Arctangent said:

It really feels like something's not being said here.

What's not being said is that the stars have aligned and for the next few weeks, I'll actually have an oppurtunity to sink 5+ hours a day most days on something fun like this.

 

I'd rather not commit to something for several weeks and then end up with an unfinished app, because I would either have to abandon it or go back to only have a small amount of time to dedicate to it, assuming I don't take away from my favorite 8 hour cat naps. I'd rather spend that time on my maps and stuffs.

 

anyways, does anyone have any advice for my new incredible gameception excursion, like with the updating and stuff

and the other parts

Share this post


Link to post
13 hours ago, Jon said:

Given how little time you’ve got, I don’t know why you’re wasting it arguing here. Like I said in my last comment, if you’re not dissuaded by what people have said, *go forth and code*!

Same. I don't think there's anything more I can add to this thread other than "just go and write some code then". Any other advice I could give, I've already said in previous comments.

Share this post


Link to post

I hope you do aim for a Android version. Android is really lacking in Doom ports. Because most of them have either been removed from the store or they are paid.

Share this post


Link to post

My biggest problem with such paid apps is that they are often derived from GPLv2'd apps, allowing them to become paid.

I think @bonnie may have better luck in trying for Android rather than iOS, because there's relatively lesser amount of people who are using iOS and a free Doom port in the Play Store is pretty much needed. I can understand how much of a hassle it can be through, so trying for iOS may be a better option.

Share this post


Link to post
8 hours ago, MrD!zone said:

I hope you do aim for a Android version. Android is really lacking in Doom ports. Because most of them have either been removed from the store or they are paid.

8 hours ago, Cacodemon345 said:

I think @bonnie may have better luck in trying for Android rather than iOS, because there's relatively lesser amount of people who are using iOS and a free Doom port in the Play Store is pretty much needed.

i don't have an android ;~;

part of why i wanna do ios is because i'd like to actually have the app on my phone when i'm done and stuff

 

double anyways, i'm gettin a little spooked with the app now because there are a multitude of deprecated thingies, and some of them seem pretty obscure, and i can't find a lot of information on how to replace them

also the code doesn't seem to include any of the resources for like menus and stuff, which is pretty bad

i mean i expected there to be no wads, but no menu graphics either?? ;~;

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×