Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 08/13/19 in all areas

  1. 1 point
    Hi there, I created this piece almost exactly five years ago as a MIDI mockup and have been working on it very intensively over the last few weeks. The whole thing was recorded with new and – hopefully – more realistic orchestral samples and re-arranged here and there. I would be happy to get some feedback, especially on the mix or the sound in general and what could be improved. Synthetically realizing an entire orchestra on a PC is really a science in itself (at least for me) and I must honestly admit that it took me at least two to three times as long for recording and mixing in the sequencer that for the actual composition in the notation program. https://soundcloud.com/dustin-naegel/a-swashbucklers-fanfare-1 As a video with excerpts from both score and sequencer: https://www.youtube.com/watch?v=a1qQsuz7TPg Thanks for your feedback Dustin
  2. 1 point
    This whole topic is pointless if you don't show the full code. We can't tell what was wrong without seeing the full code.
  3. 1 point
    Assuming that the textures are in order and come in the correct pattern for a GL_TEXTURE_CUBE_MAP, it can only be the texture coordinates or the order of the vertices, imo. Spoiler: vertices in order for gldrawarrays 😉
  4. 1 point
    Today, GameDev.net celebrates its 20th birthday. To the GameDev.net Community and the games industry, I wanted to say Thank You for the last 20 years of inspiration, education, and friendship. My name is Kevin Hawkins (khawk). I was 1 of 8 co-founders to launch GameDev.net on June 15, 1999. We started this platform as a passion project, and while I’m the only founder still involved, twenty years later it’s still a passion project for me. But GameDev.net is not about me. It’s about you, the community, and this common ground we have in game development. At times, any thoughts considering the scope, scale, and consistency of GameDev.net’s impact on people around the world for the last 20 years leaves me with a curious dose of humble pie that can be difficult to explain - few sites from 1999 continue to exist in essentially the same form as when they were launched. As a community, we all come from varying backgrounds, interests, cultures, and generations, but game development is our common thread through the GameDev.net platform. It’s this common thread found in diversity that I appreciate most. If we go back in time to June 1999, a small group of professional, hobbyist, and student developers decided to create a game development community where all types could participate - students, hobbyists, indies, and AAAs alike (all these labels did not exist at the time). A place that provided an independent voice in the games industry where students could learn from professionals, hobbyists could share their projects, and everyone could come together around the science, technology, and art of game development in a friendly, helpful, safe environment. Twenty years later that original vision remains true - and perhaps it’s been a better journey than we could have imagined. On GameDev.net, beginners learn from games industry professionals, indie gamedevs share their journeys, and artists, musicians, and sound designers showcase their skills and support each other through critique and encouragement. And since all of these skills come together on this platform, ad-hoc teams form in the community as developers collaborate on projects and encourage each other through challenges. We’ve witnessed students turn into AAA professionals, friendships form, marriages, deaths, and the birth of future generations. Many names and faces have participated in the forums, shared their knowledge with articles, offered their gamedev experiences in the blogs, and showcased their projects. Members have even become game development book authors - including through the GameDev.net series of books. Some active members have been around since the early months of GameDev.net. Others just joined. There are names you know from industry headlines. Other names quietly making a bigger impact on the world than anyone realizes. Other names you will learn in the coming years. Whatever the pedigree, GameDev.net’s success as a community has been wholly dependent on the people who decide to engage, share, and connect with others. When people contribute to the community, a camaraderie and passion develop between GameDev.net members unlike any I’ve witnessed in any other community. I know of lifelong friendships that started through GameDev.net - some of my own included. I also know of several business partnerships that have formed through group collaborations on the platform and continue to be successful today. This community has helped people turn their dreams into reality, learn new skills, and find new passions. It has even moved beyond game development and helped people cope with grief, depression, relationships, and find humor in everyday life. However GameDev.net has impacted your life - whether it was one small solution you found in search or an experience that helped you live your dreams - I hope it was positive. I appreciate the opportunity I have had to be a part of this community and the games industry through GameDev.net. I know my fellow co-founders, staff, and moderators also share in that appreciation, and most importantly, I hope the feeling is mutual for you. 20 years. Wow. Thank you. Kevin “khawk” Hawkins GameDev.net Check out member thoughts on the pre-20th forum thread here. Founders, Staff, and Moderators in GameDev.net’s 20 Year History Founders Kevin Hawkins (Khawk) Dave Astle (Myopic Rhino) Michael Tanczos Don Thorp John Munsch Geoff Howland (ghowland) Nick Murphy Ernest Pazera (TANSTAAFL) Staff and Moderators Jason Astle-Adams (jbadams) Sean Kent (Washu) Drew Sikora (Gaiiden) John Hattan (jhattan) Richard Fine (superpig) Dave Mark (IADaveMark) Ben Sunshine-Hill (Sneftel) Oli Wilkinson (evolutional) Promit Roy (promit) Tom Sloper Mona Ibrahim (monalaw) Mike Lewis (ApochPiQ) Ben Sizer (Kylotan) Emmanuel Deloget Josh Petrie (jpetrie) Chris Bennett (dwarfsoft) Nathan Madsen (nsmadsen) Andreas Jonsson (WitchLord) Oluseyi Sonaiya (Oluseyi) Josh Tippetts (JTippetts) Graham Rhodes (grhodes_at_work) Jon Watte (hplus0603) Jeromy Walsh (JWalsh) Carsten Haubold (Caste) Luke Benstead (Kazade) Mikael Swartling (Brother Bob) Yann Lombard (Yann L) Dan Marchant (Obscure) Joris Timmermans (MadKeithV) Paul Varga (Null and Void) Timothy Wright (Glass_Knife) Rob Jones (phantom) Sander Marechal Dave Baumgart (dbaumgart) Alex Walker (Sandman) Andrew Russell Yannick Loitière (fruny) Mare Kuntz (sunandshadow) Kelly Murdock Tiffany Smith Trent Polack (mittens) Graham Wihlidal (gwihlidal) Mike Stedman (Ravuya) Jack Hoxley (jollyjeffers) Shannon Barber Bryan Wagstaff (frob) Steve Macpherson (Evil Steve) Mike Caetano (LessBread) Mason McCuskey (mason) Tom Roe (fastcall22) Melissa Astle (frizzlefry) Jim Perry (Machaira) Karl Knechtel (Zahlman) David Michael (DavidRM) Sande Chen (sk8gundy) Amy Young Muhammad Haggag Heather Holland (felisandria) Brooke Hodgman (hodgman) David Michalson Matthew Anderson Bryan Ayeater (bishop_pass) Sean Forbes (riuthamus) Howard Jeng (SiCrane) Matt Pettineo (MJP) Tristam MacDonald (swiftcoder) Leigh Stringer (pan narrans) All8Up Wavinator
  5. 1 point
    On long term projects? (as per your 2 year ship estimate) Probably not... I've done some art work for other people's games, usually a few pieces for people I know (some made it commercially, others didn't). Sometimes I will do very small projects just for a portfolio piece but these are done at my own pace and with the intent I'm doing it solely for my own portfolio so I would be making something similar regardless. I personally don't care about rev share or anything else because the likely hood in getting paid is slim to none unless you're dealing with a team that has the financial capacity to market their game, and there is enough % of revenue generated to even get paid. Since 'most' rev share models are NET and not GROSS it leaves little revenue to distribute once all costs have been accounted for assuming you're in the plus. If an artist is going to work for money there is enough work out there to just ignore your lower offer and spend that time with clients that can afford their services. When you're starting out you might take such deals, but I personally wouldn't. I would want 100% and forget the equity deal. Usually people offer equity because they have no money, but when you give away equity in your business it makes it harder to gain investment later on if your project pops-off. For argument sake, If I took less than 100% I would have to see how much valve my art makes to your overall project and I would ask for equity in the business which owns the IP (the game being worked on). Even deals like % off the top of every sale. But regardless, equity deals are worthless unless the business has other ventures making money currently, or in the case the business has the ability to fully fund the marketing which is unlikely if they cannot pay for help to begin with. I stay far far away from such businesses and I get offers all the time as a programmer more so than an artist which I decline.
  6. 1 point
    My annoyances with C++: Using Standard Library makes compile times very slow and its code looks messy in the debugger. Variables aren't initialized by default (I don't forget to initialize them often, but I see lots of code that forgets) The whole #include system is archaic and easily slows down compile times. Unwanted implicit type conversion that could cause bugs. enum values can't be printed without macro magic. No standardized ABI.
  7. 1 point
    A good hint if you really want to implement this from scratch is to start simple. Begin with a sphere on a plane. Then add more spheres to test stacking. And there you go... These portions of code implements contact resolution. This is just a matter of looping over each contact sequentially solving velocity constraints. Note that this is not a naive impulse approach. This is a more mathematically correct way of applying impulses. Don't play around with some extreme simplifications or hacks around there such as the naive impulse approach if you really want to get this working reliably for multiple bodies. https://github.com/irlanrobson/bounce_lite/blob/master/src/bounce_lite/dynamics/contacts/contact_solver.cpp https://github.com/irlanrobson/bounce_lite/blob/master/src/bounce_lite/dynamics/contacts/contact.cpp All this code is called from an island. But you don't need islands in your simple engine. So you can skip this feature. https://github.com/irlanrobson/bounce_lite/blob/master/src/bounce_lite/dynamics/island.cpp With Box2D Lite and Bounce Lite and on the side you should be able to successfully implement you simple engine of dreams. Erin gave a nice talk about constraints in 2014. This should get you introduced to the topic. The accompanying material also contains some MATLAB code. http://box2d.org/files/GDC2014/GDC2014_ErinCatto.zip
  8. 1 point
    Did you check Bounce Lite? It's essentially a 3D port of Box2D Lite. Bounce Lite only supports impulse caching. Bounce supports impulse caching or contact re-clipping/rebuilding. Those are essential features in order to get a stable stacking using a small number of iterations. The latter being particularly important in 3D since the main problems here involve rotations. So basically in order for friction and stacking to work stably you need to cache impulses. Otherwise you will need lots of velocity constraint solver iterations since you don't have an initial guess. For deep contacts in 3D you also need frame coherence as mentioned above. Those are somewhat quite involving but is relatively easy to implement. Don't get desperate! Fortunately these are well understood and solved problems. All this is implemented in Bounce Lite and Bounce. You definitely need a reference code in order to get things working. Then you can add more features to your library. But please make sure you understand every aspect of the engine. It becomes much easier to debug something you can understand.
  9. 1 point
    Since the OP probably only cares about the data that's under the mouse cursor it would make a lot more sense to optimise the process around that knowledge. If I were implementing GPU-picking with a CPU read-back I would: Provide the GPU with the mouse coordinate XY via a constant buffer. Bind an Append Buffer UAV to the Pixel Shader stage with enough space for holding as many 'picks' under the mouse cursor as you might ever expect to have due to overdraw. Something in the region of 32 sounds reasonable. In the Pixel Shader, check if SV_POSITION.xy == MouseXY and then simply append a pair of values (Depth and Object ID) to the list. Be sure to add [earlydepthstencil] to the shader so you don't lose the EarlyZ depth testing optimisation. CopyResource the ~32 values to the Staging resource. Map that small buffer instead and find the one with the object ID with the lowest depth value. Optionally sort them by depth and you have yourself a sorted list of hits under the cursor. This approach has a number of advantages: Memory - you don't need an entire extra render target to hold object IDs for all the pixels you don't care about. Speed (probably, profile it) - you're not writing out this entire extra render target's worth of data and you're only copying back about ~256 bytes of data over the slow PCI-E bus as opposed to 8-32MB. Flexibility - if at a later date you decide you want to visual picks behind the front-most object you have a full list of all picks on all objects that lie under the mouse cursor rather than just the top-most one. Using your method, you might also want to think about using CopySubresourceRegion to copy back just the one texel you're interested in rather than all of the texels. PCI-E 3.0 at 16x has a peak bandwidth of 15.75GB/s. If you're copying back a 2160p R32 surface (32MB) that's going to take at least 2ms for the GPU to complete - so the less data you can transfer back the better.
  10. 1 point
    O(1) algorithmic complexity would mean the execution time is invariant to the number of particles - that would be a groundbreaking discovery!
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
    Thom R
  • 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!