• Advertisement

Endurion

Member
  • Content count

    3783
  • Joined

  • Last visited

Community Reputation

5439 Excellent

2 Followers

About Endurion

  • Rank
    Contributor

Personal Information

  1. Multiplayer Pac-man Challenge

    Regarding the 2 player part, all three options or does one suffice?
  2. Multiplayer Pac-man Challenge

    Oooh, neat I'm pretty much in!
  3. No new challenge yet? Need proposals? Staying with the arcade themes: * Pacman * Tetris * Dig Dug
  4. As a hobby developer I'm also not particularly fond of the signing stuff, as I provide my games for free. So I don't see to shell any money out for anything, esp. not periodically. IMHO this is nothing about trust. Have you personally ever checked the signature of a executable you downloaded? The suspicious warning works in a way that the number of downloads are weighed against the number of user warnings via feedback, so over time the warning should go away (IIRC this is the "Smart Screen" filter) One method could be to release your game in the Windows store. It's a bit annoying to modify, but you can use C++ just fine. To use the store costs a one time fee (ca. 17€) which I'm fine with. Still, I provide most games from a zip archive, only a select few with an installer (those who cater to rather non technical users)
  5. I think scaling up with whole numbers and blacking the rest is the proper way to go. Then you'd have good looking graphics and use as much as possible of the monitors area. I prefer having black bars to skewed graphics.
  6. No. Not color picking. You do not read back from the GPU if you can avoid it. Memory access is extremely optimized in one direction, from CPU to GPU. Since you prepare the map texture yourself somewhere, have a simple color coded version of it in memory. Check the pixel the mouse is over, color = state.
  7. A Windows Store Story - Part #5

    Progress! I managed to get remote debugging working on the tablet and found the cause of the crash bug at once: Interestingly during initialisation of the input wrapper I registered for gyro changing events before the basic input setup was complete. And, lo and behold, I received an event before the input init completed. Null pointer, bam! instant crash. Weirdly, this never happened on Windows phone. Seems UWP has some subtle differences between platforms. So now that crash cause is history and the next release is up. Now a bit more about the framework I've setup. I've tried two or three times to set up a simple UWP sample app and include the main game code in that. The sample app was setup differently (but I think I didn't do it on purpose, rather the SP of Visual Studio 2015 changed to 3 in between) With the first two tries the sample app had some XAML stuff (which I don't really like), and I never got the swap chain to work properly. With the 3d try there was no XAML document at all, and this time the swap chain worked (after a few attempts with different parameters) There's quite a few preconditions and certain parameter combinations that are mandatory. Luckily the runtime spits out a pretty descriptive error message what was actually expected. Using a generic framework for both Win32 and UWP proves a tad tricky, since UWP wants a managed main method. With a bit of pseudo global magic (I've got one environment instance where several services like renderer, logger, sound and also the main application register) I was able to refactor the main function out. So for HitBlock Deluxe I have a solution with a shared project containing the actual game logic, and a UWP and Win32 application project; both having the shared project as dependency. Current gotchas: Since UWP requires assets to be embedded, and absolutely does not want assets from outside the project folder, I share the assets from the UWP project. Ugly, but works. And there's a new crash, unfortunately without any crash info. Oh well....
  8. A Windows Store Story - Part #4

    Three weeks have passed, a few new people have installed the game. I had the chance to deploy the game also to juniors x86 tablet, where it currently crashes. The tablet does have a gyro sensor, which I thought worked fine when using it on Windows Phone, but apparently the code isn't crash proof enough. I've been looking mostly for crashes now, and a handful (well, two in the last 3 days) did appear. The crash info is all over the place. Some have a really great stack trace, other nothing. Some seem to be in between. I reckon this is heavily affected by fiddling with telemetry settings. What I'm also missing on a first glance is the configuration of the crashed app. Since the compile builds executables for x86, x64 and ARM it'd be nice to know which of these were the cause. What's always there is the name, IP, Windows build version and device type of the device that was running the game. While the stack traces sometimes help they are only that. You don't get a full dump or local watch info. So you can get lucky and the location of the problem is clear, or you're out of luck. In these last two crashes the stack traces hints on a null pointer on a method that is used throughout the game (GUI displaying a texture section). I suspect that it happens during startup and the code path went inside a function when it wasn't ready. In these cases I can only add a safety check and cleanly jump out of the function. Build, upload, re-certify and next try in 1 to 3 days. Currently I'm struggling getting remote debugging done on the tablet. I can deploy the app via enabled web portal, but the remote debugger is not properly recognized by Visual Studio. I was hoping for USB debugging as that works nicely on the phone, but had no luck with it. Well, here's to the next version hoping to get those crashes fixed!
  9. C++ buffer or vector issue

    Not entirely sure, but the moment you call erase on an vector iterator the iterator is invalid. It happens that you seem to be able to access it's content, but you really shouldn't. Put the erase call as last code before the break.
  10. Blast from the past: While checking my different renderers I've come upon a problem in a Direct3d8 renderer, which I'm pretty sure worked fine already a while ago. Basically I'm drawing a 2d quad with pretransformed vertices, but the first triangle's texture coordinates seem off. I'm offsetting the coordinates by -0.5,-0.5 as per spec and there's not much more to it. The same part with D3D11 using shaders works fine (well, duh). Anyhow, I'm still curious, as the DX8 renderer is still my final fallback and it currently is supported quite well. Anybody see any glaring mistake? The code in question is this, the texture is a 16x16 pixel sized cut out from a 256x256 texture, these values are used. FWIW I'm running on Windows 10 with some AMD Radeon 5450. iX = 22 iY = 222 Texture rect from the full texture are is (144,0 with 16x16 size) The drawn box is drawn scaled up to a size of 40x40 pixels m_DirectTexelMapping.offset is a 2d vector with values -0.5, -0.5 I've set min-, mag- and mip-mapping filter to nearest. struct CUSTOMVERTEX { D3DXVECTOR3 position; // The position float fRHW; D3DCOLOR color; // The color float fTU, fTV; }; CUSTOMVERTEX vertData[4]; float fRHW = 1.0f; GR::tVector ptPos( (float)iX, (float)iY, fZ ); GR::tVector ptSize( (float)iWidth, (float)iHeight, 0.0f ); m_pd3dDevice->SetVertexShader( D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_TEX1 ); vertData[0].position.x = ptPos.x + m_DirectTexelMappingOffset.x; vertData[0].position.y = ptPos.y + m_DirectTexelMappingOffset.y; vertData[0].position.z = (float)ptPos.z; vertData[0].fRHW = fRHW; vertData[0].color = dwColor1; vertData[0].fTU = fTU1; vertData[0].fTV = fTV1; vertData[1].position.x = ptPos.x + ptSize.x + m_DirectTexelMappingOffset.x; vertData[1].position.y = ptPos.y + m_DirectTexelMappingOffset.y; vertData[1].position.z = (float)ptPos.z; vertData[1].fRHW = fRHW; vertData[1].color = dwColor2; vertData[1].fTU = fTU2; vertData[1].fTV = fTV2; vertData[2].position.x = ptPos.x + m_DirectTexelMappingOffset.x; vertData[2].position.y = ptPos.y + ptSize.y + m_DirectTexelMappingOffset.y; vertData[2].position.z = (float)ptPos.z; vertData[2].fRHW = fRHW; vertData[2].color = dwColor3; vertData[2].fTU = fTU3; vertData[2].fTV = fTV3; vertData[3].position.x = ptPos.x + ptSize.x + m_DirectTexelMappingOffset.x; vertData[3].position.y = ptPos.y + ptSize.y + m_DirectTexelMappingOffset.y; vertData[3].position.z = (float)ptPos.z; vertData[3].fRHW = fRHW; vertData[3].color = dwColor4; vertData[3].fTU = fTU4; vertData[3].fTV = fTV4; m_pd3dDevice->DrawPrimitiveUP( D3DPT_TRIANGLESTRIP, 2, &vertData, sizeof( vertData[0] ) ); God, I hate this borked message editor, it's so not user friendly. This POS message editor really loves to f*ck up code formatting.
  11. A Windows Store Story - Part #3

    A few days have passed since I uploaded the game. I did no advertising whatsoever, but the two blog entries I had here. So I've been watching the dashboard closely, to see if somebody actually looked at and installed the game. And a handful (literally) did Joy! I even got a feedback which can all be conveniently inspected in the dashboard. Unfortunately I've also got crash reports. In one case I received a stack trace. I have a hunch what might be the cause (I've called QueryInterface without checking the HRESULT. I should've known better!) Currently I'm on vacation and have only access to a Windows 7 laptop. And unfortunately on this Visual Studio 2015 prefers to crash when I try to create new packages. I'm pretty happy I can actually compile though; and also the manual package creation via command line does work fine. Go figure. Downside, I obviously can't test or debug the compiled game at all. So I have to wait before uploading a fix to the store. In the meantime I got access to a Windows mobile phone (which is actually pretty good IMHO). Just for kicks I deployed the game and it worked perfectly. If you disregard no possible keyboard entry or back button support. Over the last few days I've made a few adjustments to the code so now back button works, and overlay touch controls are also available (for phone only). I have also tried to add tilt support (both via Gyro and OrientationSensor - the first one is not supported by that phone, and the latter seems to be lagging quite a bit). Once I manage to get keyboard support I also have to try to make the game GUI somewhat more phone friendly (a tree control isn't really all that fit for big fingers). Overall I'm pretty satisfied as how well the same app performs as pure Win32, as UWP app on desktop and on phone.
  12. Well, there's the ominous 0th law, that Giskard(?) abstracted on his own: A robot may not harm humanity, or, by inaction, allow humanity to come to harm. That ones would be able to override lower laws, e.g. might a being be harmed to avoid harm to humanity. But I seriously doubt AI will ever get that far to grasp rather philosophical concepts.
  13. Awesome, kind of Thanks a lot for re-testing. I'll have a look about the fullscreen issue. I owe you one!
  14. October 2017 GameDev Challenge: Arcade Battle Arena!

    Replaced the D for next level with Shift-D. Now that shouldn't interfere with WASD anymore. Uploaded and replaced the old file. Thanks for the feedback!
  15. I think I found the cause. The crap laptop I have here has a problem getting a proper IDX11Device2. Since I didn't even require it to be 2 I replaced that with a plain IDX11Device and it works. I've uploaded the replaced file to the same link: http://www.georg-rottensteiner.de/files/GDMissileCommand.zip If you could try to see if that one works that'd be awesome. Thanks a lot!
  • Advertisement