Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

375 Neutral

1 Follower

About cyberpnk

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. cyberpnk

    Writing portable Vulkan

    I don't have any advice, but I'm messing around with Vulkan as well and would be interested in what you are asking about.
  2. Been working on an engine in my spare time for a few years. It's been on and off, so I'm nowhere close to building a game yet. I've been enjoying the process, but it's very time consuming and it can be daunting comparing the features to Unreal or Unity. I've had doubts whether it's even a good idea, however there are some things I'm exploring that aren't well suited for existing engines (at least not without a lot of work and source level access). For me, it's more of a learning experience, so I'm okay not having something totally complete or competitive. If I were trying to sell a game any time soon, I would certainly choose Unreal or Unity and call it a day. It depends what you are looking for, I think for most people building an engine would be too costly (in terms of time) compared to free or practically free engines available today. If you are more interested in skill acquisition, building a portfolio, etc. then it can still be worthwhile. Or, like me, trying to do something really different and not easy to do in general engines, that could be a valid reason. Otherwise, I think it's more prudent to just use or buy whatever tools you can and make your life a lot easier. Just my opinion.
  3. cyberpnk

    Imperfect Environment Maps

    Great article and really inspiring. I too have been reading some old papers, and I think there are interesting ideas that sometimes get forgotten, or not revisited with modern hardware. Good stuff.
  4. cyberpnk

    Portfolio 3D artist feedback and advice

    Awesome! It looks a lot better.
  5. cyberpnk

    Any DX12 books recommanded?

    AFAIK the Frank Luna book is it right now. But it's also possibly one of the best series on graphics programing out there, so even if there is only one book available, it's a good one book to have.
  6. cyberpnk

    Portfolio 3D artist feedback and advice

    Hey. Your art looks good. For a student, it's a great start. Some comments: - The fantasy city is nice, but there is not really any animation (like character animation) so the video may hurt more than it helps. Recruiters may get bored half-way into the video and close it and that may not make a good impression. It would probably be better to have just a few high-res images as the video compression looked bad to me and didn't show the art in it's best light. - The villa was also cool, but I would avoid using Unreal default assets (the robot) as it makes it look amateur. - The other pieces were okay to me, but I think it would help to have untextured lighting only shots and also wireframes. - If you are trying to go into games, you should show better optimized models. For example, the robot at 15k tris seems way too complex, especially the feet and the bottles in the middle (which could be just a flat texture), and if you are going to show a wireframe, it should be impressive (meaning optimized for real-time). Overall, though, I think it shows a lot of potential and I wish you the best of luck.
  7. So, I'm kind of struggling with the use of Singletons as well and trying to find a good solution. As an example, in my engine I'm working on (very early stage right now) I have an Input class that wraps GLFW and provides functions for checking mouse/keyboard buttons. It seemed to make sense that this would be a Singleton, since the GLFW library (I believe) only allows a single callback function (i.e. for the keyboard) per window. However, lots of places online are saying Singletons are the spawn of Satan, so I was looking to eliminate them. I did manage to convert the class to be non-Singleton, but I'm not sure it's any better. Now I have to be sure to only create one Input instance (not so hard, but open to mistakes, especially if someone else uses my code) or else the callbacks will be overwritten. This example is probably not the end of the world, but what about for an event system? My project uses events to pass information around to different classes. The event dispatcher (or manager or whatever) is a Singleton and can be called like this: EventGetWindowSize event; Dispatcher::fire(event); resizeSomething(event.width, event.height); For example when the platform window is resized, a "WindowResized" event fires, which could recrate swapchain resources and other things that are dependent on the window size and objects needing to be resized can query the resolution using the "GetWindowSize" event shown above. I also use this same system to obtain the device pointer, which is used by probably a dozen different classes that interact with the graphics API. While I could pass the device pointer to every class that needs it, there are other events that only happen during run-time and are dynamic. The way I have it, the classes only need to import the header file for the event used to pass struct data back and forth and the Singleton Dispatcher. Neither class needs to "know" anything about the other class, or import their header, they only need access to the event data struct (used for input and output). This is especially helpful to avoid circular dependencies. To remove the Singleton would mean that essentially every class could need to be passed in the main Dispatcher object (likely on construction, since they need it to get access to the rest of the system). I could eliminate some of the events by passing object pointers directly in constructors, but many classes would still need Dispatcher access to function. If the point of the Dispatcher is that it's the central hub, and only one should exist, is it the worst thing to have it be Singleton? It would save a lot of boiler-plate code rather than having to pass a pointer to so many other classes in the system. I'm not yet at the point of multi-threading the engine, nor do I have much experience with unit testing, which seem to be the main reasons for not using Singletons. But I don't want to spawn Satan with my code, so I'm open to suggestions if there is a better way to do this.
  8. If you already have a CompSci degree, then you should probably focus on the experience and portfolio side. Most job postings I see ask for at least a 4-year math/engineering degree, so you should already be good to go there (even if it's not a super prestigious school). But the degree alone is not going to get you hired (even if it will open some doors and/or stop your resume from being trashed). So, yeah, work on some projects. Open-source is a good idea, I've been asked for source code in interviews and having something on github would be sweet, assuming the code is a good example of your skills. Making an indie game, even something simple or even if it doesn't make much money, would probably help to get you some experience and also something to put in a demo reel or send to potential employers. It doesn't even have to be a full game, for example, if you are going for a graphics coding position, maybe a sweet graphics demo (ala a 64k intro) could be enough to gain some interest, etc. Just depends what you are going for. If you want to do gameplay programming, maybe a game with simple polygon graphics like Super Hexagon or something would be fine if the gameplay was solid. People usually say to start with classic clones, like doing Breakout or Space Invaders. I think this is good advice to learn, but you will probably need something more advanced to get hired. But it's a good place to start if you haven't really done much game coding at all. Then build up your skills and try something a little more original or ambitious to make a name for yourself. Like anything else, it takes time and effort, and no one will believe you have the skills until you prove yourself. Good luck!
  9. If you have to ask, the answer is yes. Unity is about the best choice for beginners and that's a good place to start.
  10. cyberpnk

    Which Degree Should I Pursue?

    I would say go for Computer Science. Most game dev programming jobs list that as a requirement (or at least a nice to have) and it will give you a well rounded foundation for becoming a programmer. As @swiftcoder says, it also gives you some flexibility if you want to get a non-gaming job down the road. Game dev specific degrees aren't worth as much, even if you may actually learn more applicable skills. I actually had a similar decision years ago, and ended up switching from CompSci to art school and kind of think I made the wrong choice. Though I'm sure people say you can learn things on your own, etc. I find that lacking the CompSci degree has held me back from more technical positions. So I think it would be worthwhile.
  11. You should probably pick a popular resolution to target, such as 1080p (1920x1080), so that your art looks optimal. And then have the actual screen resolution be fluid to whatever resolution or aspect ratio the user has. For example, some people (like myself) use 4K TVs as monitors, it which case the screen would just scale up 4x to fit (this is easy since it's a multiple of 1080p and the same aspect ratio). However, ultra-wide screens are more popular these days and (less so) multi-monitor configurations, and it would be nice to support an arbitrary aspect ratio. In that case, your game would render art to the left and right of what would normally be seen on a 16:9 screen. In any case, it would be a mistake to hard-code a few resolutions and expect that all your customers just happen to have the same monitor you do.
  12. Good points. I'm definitely still learning but I find (limited) use of Singletons to be more convenient than passing pointers all over the place, though I agree it's basically a global variable.
  13. Honestly, I don't think there is anything wrong with using Singletons. Especially for classes you know will be accessed anywhere, it's pretty much the most straight-forward way to do it.
  14. cyberpnk

    Was it a mistake to develop my own engine?

    So, I've been on a similar journey. Off and on I've been building an engine for about 5 years. Originally in DX11, then ported to DX12, and most recently I've rewrote it from scratch in Vulkan, though I'm just at an early stage now. I think I've learned a lot, and it was a worthwhile experience, but I'm nowhere close to finishing a game after all that time. In that sense, if I wanted to finish a game, I could have done so with Unity or Unreal in much less time. However, I'm sticking with it because I have an original idea I'm not sure can be done right now in the off-the-shelf engines, and I want to give it a shot. That said, I have evaluated the commercial engines, mostly Unity and some Unreal, as well as quick tests in less popular engines like CryEngine, (the now defunct) Stingray, etc. I've found they all did some stuff well and some stuff not so much. Unity is pretty solid overall, and probably would be my pick if I had to choose one. There are some specific reasons it's not perfect for my project, and I would like a stable Linux editor, but overall it's OK. Unreal looks really nice graphics-wise, but I found the editor to be bloated (it takes forever to load, even on a top-shelf system), and is really unstable. I've had it crash when doing seemingly common things like deleting an asset from the project (and made worse since it takes forever to load up again). One time the crash completely corrupted the project and I was unable to open it again (loading the project itself would crash). Of course, I had a backup, but it still doesn't make me feel comfortable that my project could be permanently corrupted just by removing a texture. Unreal also has limited support for custom shaders, which is fine if you like the "Unreal look", but if you want to do something unique there may be hurdles. The smaller engines I tried have some interesting features but ultimately didn't look significant better than Unity/Unreal. And there is a concern of continued support with the less popular options, like the financial situation with Crytek, or Autodesk shutting down Stingray after like 2 years. That would be really troublesome, for example if you spent 2 years building a game in Stingray only to have the engine maker abandon the project. However, if your game is fairly generic in the functionality and graphics style, you could certainly do something with Unity or Unreal. In terms of the level editor, you wouldn't be using the engine editor to give to users, rather you would build a custom editor into your game itself. In which case, you can make it simple and user-friendly. Both Unity and Unreal use PhysX, which is pretty decent for most common use-cases. You can use arbitrary convex shapes, though, to your point, Unity used to support concave objects with an older PhysX version, and then Nvidia removed that feature. While you can still simulate concave objects with a set of convex shapes, it would require some rework if you had built your game around this functionality. In my case, I'm investigating advanced physics solutions using the GPU, and this is a little difficult with commercial engines. While it can be done, it feels like you are fighting the engine in a way when attempting this. For example, in Unity, you could write a physics engine in a compute shader and then render dynamic objects. However, if you do this, it bypasses all the standard material shaders, in which case you lose shadowing, lighting, etc. So you'd have to rewrite the lighting and shadowing yourself and then hope it plays nice with other objects that are rendered normally. Unreal, on the surface, seems better since you have the source code and can make arbitrary changes. However, if you want to update the engine, then you'll have to manually merge those changes every time you want to update, and things could break in unexpected ways. At that point, you would have to have extensive knowledge of the code-base and would probably be capable of writing your own engine. All that said, if you are making a vanilla game, then the existing commercial engines would probably do fine. They have their pros and cons, but they cut out a ton of work for you on day one. If you are trying to do something more innovative, I think custom engines still have a place. Even if not, working on one is a great learning experience and definitely a solid way to gain some skills. I've gone back and forth over the years (and abandoned and restarted the project several times) but I do think it can be worthwhile in some situations. Good luck!
  15. Best to use a capture program for this. FRAPS is very old and my not be reliable for all programs. On Windows, you can use MSI Afterburner, or the apps that come with your graphics card (Nvidia ShadowPlay or AMD ReLive).
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!