A lot of game genres, such as racing and platform fighting games, rely on a gamepad rather than a keyboard and mouse for the best experience. This means these games can now be played on the web with the same gamepads that are used for consoles.
This link provides a nice article about how to use the Gamepad API in games.
A rather old (but nice) article by about self-registering c++ objects. quote from www.drdobbs.com:
An interesting design limitation with C++ is that all the places in the code that create objects have to hardcode the types of objects that can be created because all the usual methods of creating an object in C++, such as
new(classname), require you to specify a concrete type for the class name. This design breaks encapsulation. The situation is understood well by many beginning C++ designers, who try to find a virtual constructor that will create classes without knowing the exact type. These beginners quickly find out that C++ doesn’t have such a thing.
Since the functionality isn’t built into C++, I will add it by creating a class that can create other classes based on some criteria instead of a concrete type. Classes designed to create other classes are frequently called “factories.” I’ll call the class described in this article the “specialty store,” because it only works with objects that are closely related and it leaves the actual work of creation to other classes.
At compile time, the specialty store has no knowledge of the concrete classes it will be working with, but those concrete classes know about the specialty store. There are two remarkable things about this arrangement: A specialty store doesn’t contain a single
newstatement; and the specialty store’s implementation doesn’t include the header files for any of the classes that it will create at run time. (Instead, when the specialty store is asked for a new object, it queries the classes it knows how to create, asking each if it is appropriate for the current situation — if so, then that class is asked to create an instance of itself.)
For the entire article and the source code, follow this link.
This started as a quick fun project to do for breaking a bit apart from the usual daily stuff and mainly consist of building a ‘hello world’ application, install it on the modem’s flash and run it, instead of modem’s own firmware. The guinea pig will be a Netis WF2419D router I got cheaply some while ago, and just gathers the dust in the house.
If you wanna play with your modem, please note: You can render your modem unusable (this will, for sure, at least erase parts the existing data from the flash, leaving your modem unable to perform it’s modem duties). While probably there is a way of recovering from this (reinstalling the original firmware), if you manage overwrite the bootloader section of flash, it will become a paper weight (probably can be recovered by interfacing it with a JTAG or maybe removing the flash and copying data into it from another router’s flash). Anyway I take no responsability for your actions, broken modem, burned down house or whatever problem might happen because of this post.
Opening up the modem and getting out the circuit board, it’s packed with the following:
- Realtek RTL 8196C SoC
- RTL8192CE WLAN chip
- Winbond W9812G6JH Ram (16 MB as 2M x 4Banks x 16 Bits SDRAM)
- EON 4 MByte SPI flash
Lauren Ridge and Richard Hinckley show you how to build a Match 3 game using C++ in combination with Blueprints. In this first part of the series, you’ll get an overview of the game – including how to design your project utilizing both C++ and Blueprints – as well as starting to implement some of the base classes.
Part 2 continues with Lauren Ridge and Ian Shadden showing you how to use the coded move type and tile type to do visual and audio effects in blueprints, and the combos accelerating tiles.
In the 3rd part, Lauren Ridge and Richard Hinckley show you how to add swipe control to the Match 3 game using both the mouse and touch input. This is a must see for any mobile game developers out there!
Read the rest of this entry →
For the entire article and the game mechanics explorer, follow this link
Our premier VR experience takes you through a cinematic, bullet-time inspired action scene. Showdown tookOculus Connect, GDC and SIGGRAPH by storm, and now you can download it for free, including its entire Unreal Engine 4-based content library!
The interactive demo is compatible with Oculus DK2 and up, Sony PlayStation Morpheus and HTC Vive SteamVR.
The project and all assets are available for download immediately through the Learn tab on the Epic Games launcher.
Source from here
While writing my own assembler for ARM, I realized that an instruction fuzzer can spot some funky results on real CPUs. Undefined behaviour is a known topic for some ancient CPUs like z80, where many undefined instructions have been analyzed and exploited in order to achieve some performance tricks for the demoscene.
But undefined behaviour on modern SOCs and CPUs is not really a known topic for several reasons. First one is that there are several manufacturers and models for every single architecture, and in addition, the microcode is not documented and distributed in encrypted form, so understand what an instruction really does is hard.
This is also a problem for compilers and handwritten assembly optimizations which tend to require several fall-back implementations depending on the CPU model because the same instruction performs different on different chips.
As long as ARM is a fixed-length instruction length (except for Thumb2, which is quite easy to handle), it makes fuzzing those instructions easier than say x86. By understanding how instructions are composed you can quickly reduce the amount of instructions to fuzz.
And this is how I found 4 bytes that hang the RPI CPU; this undefined instruction doesn’t requires special privileges, so any user can execute it and brick the board. Requiring a hardware reset to bring it back to life.
A tiny ELF can be cooked with
$ rabin2 -a arm -b32 -C elf:fedeffe7 killrpi
Radare2 allows us to quickly check that instruction with different disassemblers.
$ for a in arm arm.gnu arm.winedbg ; do rasm2 -a $a -b 32 -d fedeffe7 ; done trap ; <UNDEFINED> 0xe7ffdefe ldrbt sp,
This doesn’t seems to show us anything useful, so let’s go deeper with the documentation:
- http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html (requires registration)
So we can now decompose the bits of that instruction in order to understand what it is supposed to be doing:
BYTES: E7 FF DE FE E 7 F F D E F E 1110 011 1 1111 [imm12] 1111 [imm4]
So, acording to this documentation, that instruction is decoded as
UDF, which is a variety of instructions that are undefined by definition and are used by debuggers to set breakpoints.
But, why only that specific construction hangs the board? Digging a bit in Google looks like this sequence is used by the Angel Debugger, which is a hardware debugger that is attached to the board using the JTAG connector and that specific core seems to enforce that exception to wait for reply.
The only way to bring it back to live is by unplugging and plugging back the power.
This bug only affects all the models of the first Raspberry PI. The RPI2 is not affected, as well as other ARM devices (phones and tablets) I tried… but maybe, other instructions provoke similar behavior 🙂
Follow the original link for more information.