Announcement

Collapse

Welcome to the all new QuakeOne.com!!

Welcome to the all new QuakeOne.com! The web site has been moved to a brand new web host, and the site software (vBulletin) has been upgraded to the most recent version. All previous data, including users and posts, has been converted over to the new version of the site.

We are still in the process of updating the site look and feel. We hope to have this updated shortly. In the meantime we have simply launched the site with the default software templates so as to not keep the site down any longer.

Until we get the site back up and running as it was before, please use http://servers.quakeone.com to find game server stats.

If you find any issues with anything on QuakeOne.com, please let us know in the Site Feedback Forum.

Thanks for your patience!

-Solecord
See more
See less

Trying to understand darkplaces source code

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Tried to run darkplaces, fte and quakespasm on a potato pc.

    darkplaces had like 1 fps, on lowest preset, didn't find a way to make it go higher.

    fte on faithful: up to 200 fps, 60 average and 35 in water. Graphics glitches a bit with 2d elements: when in game menu, bottom of the screen flickers, doesn't get rendered. Gui also flickers sometimes.

    fte on dynamic: that glitch doesn't appear, but only 3 fps.

    quakespasm: doesn't work because it's x64

    Comment


    • #92
      Baker does make one point (in his own way). What is the ultimate goal of all this work?

      To some degree it seems like you are trying to strip down an advanced engine. There are already "clean" quake sources.
      Last edited by MadGypsy; 06-30-2017, 07:23 AM.
      X_Michael

      Comment


      • #93
        @MadGypsy
        Um. I want to make a video game. I'm afraid of doing it from a complete zero, so I'm studying an existing one. I'm not really good at C and everything that comes with it, so I'm studying it in parallel.

        I'm throwing stuff away because it's my way of learning this engine. If you have a better idea how to do it, tell me.

        I'm not really doing QuakeC tutorials because I'm not very interested in it. I'll maybe do it later, after I understand the main code.

        I'm not going for the original quake sources because they are probably terribly outdated, while other source ports still keep with the times. Hopefully.
        Last edited by vibok; 06-30-2017, 07:43 AM.

        Comment


        • #94
          webquake. It's small, modern, basic and platform independent.
          X_Michael

          Comment


          • #95
            Pretty cool, thanks. I'll look into it.

            There should be a nacl version somewhere too, I need to google that. Sounds like a really cool technology, but I never really dived in.

            I'm still going to continue playing with darkplaces for a bit. Just because I'm almost finished figuring out it's makefile. I need to port it to codeblocks ide, and turn some of comments into doxygen comments.

            Comment


            • #96
              Huh, I need to setup a server to play WebQuake locally. Also, WebQuake has yet another convention for music filenames, media/quake##.ogg instead of music/track##.ogg. (trivial to change)
              Last edited by vibok; 06-30-2017, 12:35 PM.

              Comment


              • #97
                okay, a few things. if you just want to get things to a point where you understand them then ditch the whole windows api bullshit. learn SDL2 stuff only. its simpler, AND its more portable. Yes its an extra dependancy, but then so too is the winapi stuff, in a way.

                spending your time finding and isolating the parts that you DON'T want is basically a waste of that time. If you're planning on forking DP then fine, but if you're trying to write your own engine then its purely wasted time. If you're trying to make a mod for DP then forking the engine to strip stuff is in the long run just going to make it harder to maintain. At the end of the day, an entire engine is a really complex beast, by the time you've learnt one subsystem, you'll have forgotten the previous one. Either way its really only the overview that you need to learn, anything more than that and you should know where to look up anything more that you need.

                Not to contradict Baker, but if you really want to learn then building something from scratch and then stripping+copying over parts of the individual subsystems into an otherwise-from-scratch engine would be much more interesting and therefore more effective way to learn how a game engine works. Nothing shows that you understand something better than building an alternative to it.
                Some Game Thing

                Comment


                • #98
                  lol...Spike said a bunch of stuff that I had decided not to. My last post was actually pretty close to what spike said with links to a few "simpler" engine sources. At the last minute I changed it to what is there now. I had decided it would be easier to give you the most simple code I know of and let you come to your own conclusion that the overview method is the only one that is going to work with it because, there isn't really anything to strip.

                  Also...didn't LordHavoc use a bunch of macros that make it complicated to tear apart/modify his engine? I seem to remember Baker commenting about that around a year ago.
                  X_Michael

                  Comment


                  • #99
                    Guys, have you managed to understand SDL2 source code? I tried some time ago with SDL1, but failed. One of it's comments just said "if you don't like seeing complicated #ifdef code in the headers, then don't look".

                    Also, how to use memory mapped file if not with winapi?

                    Comment


                    • My main points of interest currently are: rendering, physics, memory handling, file handling. If somebody knows how to find them, please share.

                      Comment


                      • the point is that you don't need to understand the SDL2 sourcecode, same as you don't need to understand the winapi sourcecode.
                        What you do need to understand is the API that SDL2 provides to you, and that is much simpler than the alternatives.

                        here's a good place to start: https://wiki.libsdl.org/APIByCategory
                        You'll need to call SDL_Init to init whatever subsystems you're actually going to use, but after that you're free to call any function you want.
                        eg call sdl_createwindow to create a window, or SDL_PollEvent to try to read the next event for you to handle.
                        if you want to use opengl, create a window then call SDL_GL_CreateContext (you'll find some example code there).
                        It doesn't show EVERYTHING, but if it did there would just be too much noise.
                        It doesn't document opengl itself, which is an entirely different beast, SDL just shows the helpers that it provides to create an opengl context, you have to do the rest yourself.
                        Some Game Thing

                        Comment


                        • There will be so much trash inside my executable if I'll just use libraries blindly. Both programmers and users usually ignore that. Who really cares if your exe is 1 MiB or 10.

                          GLFW looks just a bit better than SDL2. Haven't driven into it either yet. Raw winapi is the best, and also the biggest waste of time.
                          Last edited by vibok; 07-01-2017, 04:38 AM.

                          Comment


                          • You are starting to remind me of SSBoxer. That's not meant as a bad thing...just a true thing. I knew infinitely more than him regarding what he should do, he kept trying to go his own way and he hit wall after wall. You have a super talented and accomplished programmer (spike) giving you guidance, you are trying to go your own way and you are going to hit wall after wall if you aren't hitting them already.

                            I think the point here is clear. Start building an engine and use SDL2. Actually, even more accurately, forget the engine for right now and just start practicing with SDL2. You aren't going to sit down and just build an engine from A to Z no matter how much you learn about other engines. Get one textured poly to render in a 3D context and build from there.

                            For the record, I have built a huge chunk of a working engine and although I haven't accomplished as much as people like spike, Baker, etc... with it, I am light-years ahead of where you are. I got that way by sitting down and actually programming. I didn't spend any time trying to understand everything before I start. I got a poly to render, then I turned that poly into a bsp, then I learned more and turned the bsp render into a better bsp render... on and on.
                            Last edited by MadGypsy; 07-01-2017, 07:32 AM.
                            X_Michael

                            Comment


                            • I actually already wrote a small window in winapi, and text rendering in opengl. I paused to look at how real engines do these things before moving forward.

                              I need to learn how they organize memory, and details about rendering, and how to write large programs in general. So far I only found keyboard handling.

                              Comment


                              • @large programs in general.

                                ALL of my very extensive studies covering numerous languages has led me to decide and agree that you should actually write a bunch of smaller programs that have as few dependencies as possible and then write a class that combines and coordinates them.

                                For one, if you do it that way you end up with a lot of reusable script. An example would be my math expression parser. I can drop that parser in any project and it's ready to use. My content manager is the same way. Actually, everything I've made is this way... Lots of idea specific API's that can be used as is in any project.

                                Let's assume you write a solid renderer. It shouldn't be married to anything. You should be able to drop the renderer in any project without dragging along an entire game engine.

                                Quake engines are generally one big dependent package and look how hard it is to track everything down. Imagine if all the concepts we're their own API and they were being combined and coordinated by a main script or 2.

                                Another perk is testing. With mini independent APIs you don't end up with situations where thingA has to be completed and functional before you can test/work on thingB, thingD or any other thing. Rip progs parser out of Quake and tell me it's still rendering the BSP. You can't and it won't.
                                Last edited by MadGypsy; 07-01-2017, 10:06 AM.
                                X_Michael

                                Comment

                                Working...
                                X