• Advertisement

Tape_Worm

GDNet+ Ad Free
  • Content count

    1197
  • Joined

  • Last visited

  1. Programming Languages

    I hemmed and hawed over whether or not to point this out (I hate being the "um, actually" guy... it's annoying). But considering that this is "For Beginners", I feel it's important that newer programmers have accurate information. Especially since I see so many people come in to my work place with a BSc in Comp Sci and end up having lot of trouble understanding the tools they're using due to bad information, or misconceptions derived from observation. C#, as in the language that comes with .NET/Visual Studio, or Mono, is most certainly not interpreted. That said, it could be interpreted, just as C++ could be interpreted. But for all intents and purposes, it is not. C# with .NET/Mono compiles down to IL (intermediate language, it looks similar to assembly), and then the JIT (Just In Time) compiler compiles the IL into native machine code. Remember: JIT != Interpreted. Interpreted languages are not converted to assembly. They're executed by an interpreter. Hence why they're called "interpreted". From wikipedia: Be aware that any interpreted language is likely going to be much slower than a compiled one. Does that matter? The answer, like so many answers when it comes to Gamedev is: It depends. But just throwing that out there, because it often does impact the decision of so many developers, gaming and otherwise. I can't speak for Python, but I think JavaScript is a little more murky on the subject especially depending on the browser you're using. However, I am not an expert in either language so someone else might be able to clear that up.
  2. I don't know if it's possible, but it'd be real nice if we could customize our front page portal. I just noticed the current layout change when I logged in, and I found it quite jarring and busy looking. I mean, I'll get used to it, so it's no big deal. But still, it'd be nice if we could define our own layout. Also, you could offer it exclusively to one (or more) of your GDNet+ tiers, thereby incentivizing people to sign up for that feature (I would upgrade my account for this + ad free in a heartbeat). To give an example: I really don't need (or want) the sections about contractors, game jobs, image of the day, upcoming events, who's online, etc... It'd be nice if I could hide these or collapse them in some way. I know this would not be trivial to implement, but if ever you get everything done, and you're so totally bored that you need something to do, then this is something you might want to consider?
  3. visual studio code

    It'd be helpful if you told us what you did to solve it, if only to avoid this: https://xkcd.com/979/
  4. Upvoting and Downvoting

    Yep that did it. I see it now. Thanks
  5. Upvoting and Downvoting

    Yeah, don't see it. At first I thought it might be uBlock filtering it out, but I disabled it and still didn't see anything. Tried Edge, and still nothing. I mean it's not the end of the world, but I just figured you guys had finally done away with that system or something.
  6. Upvoting and Downvoting

    You do? I can't see anything related to up or down voting. Which is too bad, because I wanted to give someone an upvote for giving me some good help there the other week. Or is this some new fangled method only the young folks understand like swiping SSE or NW or some such?
  7. Well damn. I remember reading about that ages back, but totally forgot about it. Makes a lot of sense now. That said, the docs for D3D11_CPU_ACCESS_FLAGS should be updated to include a link to that info eh? I've sent feedback regarding that. Thanks for the clarification. I'd give you an upvote or whatever they're using nowadays for that, but I have no idea how that system works anymore. Clearly I'm old and can't handle change.
  8. So last night I was messing about with some old code on a Direct 3D 11.4 interface and trying out some compute stuff. I had set this thing up to send data in, run the compute shader, and then output the result data into a structured buffer. To read this data back in to the CPU, I had copied the structured buffer into a staging buffer and retrieved the data from there. This all worked well enough. But I was curious to see if I could remove the intermediate copy to stage and read from the structured buffer directly using Map. To do this, I created the buffer using D3D11_CPU_ACCESS_READ and a usage of default, and to my shock and amazement... it worked (and no warning messages from the D3D Debug log). However, this seems to run counter to what I've read in the documentation for D3D11_CPU_ACCESS_FLAG: The bolded part is what threw me off. Here, I had a structured buffer created with default usage, and a UAV (definitely bindable to the pipeline), but I was able to map and read the data. Does this seem wrong? I'm aware that some hardware manufacturers may implement things differently, but if MS says that this flag can't be used outside of a staging resource, then shouldn't the manufacturer (NVidia) adhere to that? I can find nothing else in the documentation that says this is allowed or not allowed (beyond the description for D3D11_CPU_ACCESS_READ). And the debug output for D3D doesn't complain in the slightest. So what gives? Is it actually safe to do a map & read from a default usage resource with CPU read flags?
  9. I use a program called DB Browser for SQLite for my front end. Is it good? Meh, it's good enough. There's probably better out there if you look. I don't know of anything that'd convert from MDB to SQLite for you (but I haven't looked either, haven't had need to), but if you can't find anything then you could write yourself a little one-off console app (in 32 bit to keep Access happy). This app would just create the SQLite database, and transfer the data from your access database into SQLite. Then you can discard the Access stuff for good and use that SQLite database going forward. That really shouldn't be too difficult to do. You can totally make a SQLite database for Database B at runtime. It's super easy to do. Hell, if you want, you can attach the two SQLite databases together (Access provided a similar functionality with linked tables if I recall) at run time and transfer data using just SQL queries without having to write code to loop through a record at a time or whatever. Or, you could just read from those tables in A, and write to B, using the same database connection if you attach the databases. Whatever you choose is up to you, but that's some of the capabilities you can take advantage of. One tip though. To get maximum performance out of SQLite when adding/updating a lot of records, you should do it in a transaction. It's blazingly fast this way. If you don't do this, then it can pretty slow doing massive inserts/updates.
  10. OK, well, I've read your original post a bit closer and I need clarification. You have an .MDB being packaged with your app as a read only database (Database A). You have another .MDB (Database B) which is located.... elsewhere? Are you creating this secondary database from your application? You say it's not distributed along with the app, and I'm guessing you don't mean you're accessing it over the internet (very bad idea with Access). So I can only assume you're creating the database from scratch on the initial run of your application. If this is true, then SQLite will serve you quite well as it's just a file on your harddrive like Access. Only SQLite is far superior in that it supports huge databases (Access has a 2GB limit if I recall), and does not require special drivers like JET or ODBC or whatever. We use SQLite at work as a staging database for our SQL server and it's been awesome (especially for performance). If I'm wrong, and you're accessing database B remotely... then you're out of luck. Using Access for this is a bad move. While Access is technically multi-user, it's not very good at it. In this case your only bet is to use SQL Server or another type of remote database (Postgres, MySql, etc...). That said, for the sake of security, you should never access a database directly through the internet and should at the very least put it behind some sort of WebAPI (Web Services, WCF, etc...). Just in case you do want SQLite, just add a reference to it in your project using NuGet: https://www.nuget.org/packages/System.Data.SQLite.Core
  11. Alternatively, if you really must use Access*, then this article might help: https://datasavvy.me/2017/07/20/installing-the-microsoft-ace-oledb-12-0-provider-for-both-64-bit-and-32-bit-processing/ * Honestly, you should push to try and get away from that awful database, you'll be better off in the long run.
  12. NeHe OpenGL Lessons now on GameDev.net Github

    FYI, your github link is actually a facebook link: https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Fgamedev-net%2Fnehe-opengl&h=ATOQgJ9PkGw_qTFx51QKjB2HdbP5PK829CFfwnoiYDGIpM8a3wfqCmsMluhG-xLClWKfvel5jptLwQ3Vgp6aHIJyA91X2FgPqMXjBU6pJNHEHlxkW4MveKNk0I7Z1RX6BSK6STbSRyIGwP56m3aobN6n-uYQ85cMT01RTZ6icSxqHPytCT2WG4P9KIAvIYvxJ7H2c_dfG54cHl4Apq33CBLrdrMjk93g4odU7bLsRQJv8tii267-NSkvaPR6aHmFHCKtVbFV7aQDqEub0x361wM7EjG4SlWdxo2h
  13. One thing to watch out for is the LOH (Large Object Heap) for objects that are 85k+. Unlike the other heaps it is not self-compacting. This can lead to fragmentation on the heap and then you may run into an OutOfMemoryException which is pretty fatal in .NET land. We've had this happen at work when processing many large text files over and over with the end result being an OutOfMemoryException even though the application had not come anywhere near an actual out of memory situation. You can manually compact the LOH, but it's not recommended (especially due to using GC.Collect) and it's incredibly slow. Of course, this is only a problem in specific scenarios and it may not apply to your situation. But, it's always good to be aware of these kinds of issues, especially in a server environment.
  14. ads_2.PNG

  • Advertisement