• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

henryksienkiewicz

Members
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

178 Neutral

About henryksienkiewicz

  • Rank
    Member

Personal Information

  • Location
    Poland
  1. Hi, I think it's just the matter of experience and it's possible to learn how to solve problems (there are even common techniques to approach different problems - like dynamic programming). To the project Euler and Top Coder I'd add also Rosalind - http://www.rosalind.info - there are problems in area of bioinformatics, but still pretty interesting and include a number of classical CS problems. There are usually helpful tips which can help, and problems are organised such that the more difficult problems require the solution to the simplier ones. Also I wouldn't take all of they said about you as absolute truth, this is some input you got, but it's not end of the world and all that it means is some manager from that company doesn't want to hire you at this exact moment on this exact role. And pretty much it.
  2. Hi,   You will need a toolchain (an ARM cross compiler and C runtime libraries), you can get it from linaro: http://www.linaro.org/downloads/ source of nice tools & stuff for ARM development. You'll need to have the arm compiler in path, ARCH variable set and also CROSS_COMPILE having with the prefix of your toolchain. There are couple of slides about cross compiling the kernel here: http://free-electrons.com/doc/training/embedded-linux/slides.pdf And I'd recommend getting a Linux instead of Cygwin on your workstation for Linux system building, in practice it's very convinient (but I think not a must).   ;] I chosen nickname after Henryk Sienkiewicz, Polish writer (and Nobel prize laureate in literature ;]). br, hs
  3. Yes, forgot to add a disclamer - I totally agree that it's unreadable. "," is rarely used for executing statements in sequence. And using it in a function call makes things even more confusing. Cheers, hs.
  4. Hi, I don't have ready answers to most of your questions. I can give you some general tips though. arch/ directory in Linux kernel tree contains various architecture-specific code (not whole kernel for given architecture), majority of Linux kernel code can be used on all architectures. Regarding arm vs arm64 - arm64 refers to new ARM architecture (ARMv8), which AFAIK is not yet very popular, in Tegra-3 you have CortexA9 MP Core, which is bases on ARMv7-A architecture, so you're more interested in "arm" arch sub-directory. I doubt there's single distribution dedicated to Tegra itself, as Tegra is "only" a SoC - this determines which drivers for interrupt controller, memory, storage, ethernet, i2c, spi, usb, graphics etc. you will need. This is only part of the story, as there are board-specific components, which also affect the kernel image and needed drivers (like the flash layout and other peripherals connected to SoC over i2c or spi for example). You can download linux sources, and try to configure and compile a kernel (without buildroot - which will automate things for you later on, when you will have a ready configuration and learn how to use it). With Linux you'll have a number of ready board-specific configurations, but usually when porting linux to embedded devices you will want to create your own configuration file which will have all needed drivers (this is probably already done for OUYA and most probably is part of their repo). You can get a lot of information about what's supported in Linux by simply running "make xconfig" or "make menuconfig" and reading help for various configuration options. Just make sure to export ARCH variable so you will get configuration options for ARM instead of your host architecture. Note that using and creating Linux on embedded is slightly different compared to how it's done on PCs. For PC it's easy to prepare a generic kernel image which will run on most (if not all) of PCs. In embedded world you'll want to have a kernel which is tailored for your board, this also applies to the boot loader. Boot loaders here do what you would expect from typical "boostrap" bootloader which simply starts the OS, but also does pretty much ALL what is done by BIOS in PC (that is e.g. configuring your memory, initializing your CPU, caches, etc. - some things most of people receive for free and usually aren't even aware it happens ;] by simply booting their PC's. That's why boot loader is so important. Deployment also differs and may be sometimes (depending on hardware) pretty risky without HW debugger. When you're developing your OS, e.g. on a board where U-Boot is used as boot-loader you usually have rootfs image mounted via NFS, and kernel image fetched over Ethernet. When you have your flash image ready with your distro you can flash it using boot-loader (if it has such functionality, U-Boot has), over the OS (if you have one running and properly configured so it allows that) or over JTAG (if you have hardware debugger, appropriate software & hardware (on board) in place and configuration for your board&SoC). I don't think OUYA has HDD btw, most probably you will want your rootfs to be read-only with your distro + some journaled fs NAND partitions for user's data. (But of course it's all up to you as the system designer). From what I understood from the kickstarter project the authors claim the project is "open" thus most proabably you could try to get some documents from them regarding memory layout, board schematics, flash size, etc. it's usually helpful during development. Regarding the renderer - I don't know how ambitious your plans are - but there are several "display servers" or graphical environments available for Linux, most popular is X.org which most probably supports Tegra's GPU out of the box (or with appropriate drivers from nvidia's site). This is long story in general, you'll find a lot of usefull knowledge on free electrons, Internet, books, etc. I think it's too large topic to cover it in a forum post ;]. BTW - Android is actually Linux distro, for a good start you could try to get root there, mount a filesystem with your user-space applications over the network and try to get them running. Maybe even there's U-boot there with shell/console available over UART (getting this done on a commercial-ready product may require some soldering, but if you know someone specialized with electronics and have the schematics of the board, it should be easy to get it done, it's also possible without the board schematics, if you have datasheet of the SoC or a lot of time and patience), so you could start your OS by simply instructing the boot-loader/kernel to boot your OS over ethernet. Good luck, hs. EDIT: Sorry for this lengthy wall of text, added some spacing before paragraphs ;-). Found some interesting stuff btw - there are high-res photos of OUYA board here: http://www.ifixit.com/Teardown/Ouya+Teardown/14224/1 which say a lot about the board itself. There's also a concept document from nVidia regarding how Tegra boots: http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html - it seems it has a boot-rom which does early initialization of storage with actual boot-loader, configures RAM and copies the boot-loader there, and starts it. By taking a brief look at the board layout it doesn't seem there's any other persistant storage there except the NAND flash. Thus if you'll work hard enough to break things on flash you may brick the board (which most probably may be revertable if you get the jtag working).
  5. Hi, I don't know details on OUYA hardware specs, but basically if you want to make an embedded Linux distribution one way to do it is to use some existing build systems like buildroot: http://buildroot.uclibc.org/ or open embedded: http://www.openembedded.org/ and customize them. Such distributions are crafted in a way that it's possibly to make a "clean" customization - like by adding patches, component configurations and "recipes" to existing build system. You probably will want to use OUYA's patches to Kernel and possibly boot-loader (for early HW initialisation), or use their own build loader and integrate it with the build system and simply choose the components you like (and add your own). In general there are really good free resources on porting Linux to embedded devices on free electrons: http://free-electrons.com/ . Personally I had some good experiences with buildroot and openembedded (with buildroot being a bit more "clean" + it's much easier to start with, you even get ready configurations for running your distro in qemu environment). Good thing is that it seems they already published the kernel (on github: https://github.com/ouya/ouya_1_1-kernel), you'll probably want to get some info on boot loader. br and good luck, hs.
  6. You could use , operator, e.g.:   #include <stdio.h> void fun(int *x) {         printf("%d\n", *x); } int main(void) {         int i = 0;         fun( (i = 5, &i) ); } Cheers, hs.
  7.   Yeah, and not only clean but also "sane" and with performance in mind. I remember seeing some code recently which copied a buffer into an STL list of bytes. It looked clean but it was simply *wrong* (or stupid?).   Anyway if you want to start learning assembly one way to do it is to start writing some small routines in C and disassembling them (with debuggers like gdb you are even able to have a view of disassembly with interleaved corresponding C code (I mean /m switch here)).    But with learning assembler you need to know a lot of things around like ABIs of your target platform, details on ISA, details on syntax of your assembler of choice. It would be also nice to have some idea about linking and C++ ABI if you want to use assembly with C++ code. And if you want to write in asm to get better performance you'll want to know timings of exact mnemonics on your target processor and details on how your target CPU works. And even if you make your code super-optimal for certain core it probably won't have the same performance on different one (e.g. intel vs amd, or even various intel chips). It's all very interesting knowledge, but it's really lots of it and I seriously doubt you could write anything more optimal in terms of performance than what modern compilers can generate for you. + if you want it for making games then probably you mean intel ISA, and this brings even more details and problems. I don't want to discourage you, I think it's still worth knowing, but not exactly for making computer games.   Cheers, hs.
  8. Hi,  I think if you're going public with those interfaces then detailed documentation and clean design will be highly appreciated by your users. Just a couple of hints:  - you can use really good examples how to write well documented code. Personally I find Qt project documentation really well maintained, take a look here: http://qt-project.org/doc/qt-4.8/modules.html or take a look at boost documentation,  - try to avoid lies in your comments, it may sound obvious but bugs in documentation are really frustrating (I would even say it's top priority, it's better to leave some behavior undefined than write something in the code differently than in the comments or docs - this also applies to naming),  - when you write Doxygen docs, make sure it generates well - some people prefer to read the documentation without downloading whole package to see if it has what they need. I mean here just run doyxgen, and see how the generated document looks like, check the output for warnings, missing statements, etc. it will be easier to publish it later.   Thumbs up for taking the effort and documenting your API's, hs.
  9. Hmm, aren't templates the way to achieve duck typing in C++ ?   I mean your Python example:   def integrate_position(o, dt):     o.position = o.position + o.velocity * dt   could be written in C++ as following: template <class Movable, class Period> void integrate_position(Movable o, Period dt) {  o.position = o.position + o.velocity * dt; } You can use it simply: integrate_position(objectOfMyType, whateverAmount) and the compiler will generate the code for appropriate types.
  10. Hi, on a side note from the original problem, have you tried using boost program options? http://www.boost.org/doc/libs/1_53_0/doc/html/program_options/tutorial.html I haven't used it myself but it looks like it has everything what can be interesting in terms of passing command line arguments.
  11. Hello, to answer the original question:typedef enum STATE{MENU = 0, PLAY = 1, CREDITS = 2} m_CurrentState;Creates two type names: enum STATE (in C++ also available simply by STATE) and m_CurrentState. Note that m_CurrentState is a type name in this case, which makes the m_ prefix very misleading.  enum STATE{MENU = 0, PLAY = 1, CREDITS = 2} m_CurrentState;Creates enum STATE type and declares a variable m_CurrentState of enum STATE type.