Pascal graphic unit - graphics

This is going to be an Object Pascal question again.
I know what you all will say now, "We've got 21st century and you are willing to make graphics in language older than the planet Earth !?".
Well.. yes, but just a simple one, becouse I have to.
I need it in a tiny little game that normal console window, with CRT, is not exacly what I need.
What I want to ask is You is what standard (! no custom extensions !) unit should I use.
Is Graph a good choice ? I've seen many posts about people complainig, is it safe to use ?
I have checked it already by myself and few things got my attention:
Is graph window name changeable ?
Is the main console hideable ?
Can you detect the manual graph close (easly) ?
Maybe you can suggest me some other (better?) graphics unit ?

Have a look at the demoes (fpctris,samegame) that come with Free Pascal. They demonstrate a games in a pure console version and a graph version.
Don't know
On Windows, yes, use "wingraph" instead of "graph"
no idea.

Related

Gesture Recognition for my Grandma (Kinect) Linux

I'm looking into making a project with the Kinect to allow my Grandma to control her TV without being daunted by using the remote. So, I've been looking into basic gesture recognition. The aim will be to say turn the volume of the TV up by sending the right IR code to the TV when the program detects that the right hand is being "waved."
The problem is, no matter where I look, I can't seem to find a Linux based tutorial which shows how to do something as a result of a gesture. One other thing to note is that I don't need to have any GUI apart from the debug window as this will slow my program down a fair bit.
Does anybody know of something somewhere which will allow me to in a loop, constantly check for some hand gesture and when it does, I can control something, without the need of any GUI at all, and on Linux? :/
I'm happy to go for any language but my experience revolves around Python and C.
Any help will be accepted with great appreciation.
Thanks in advance
Matt
In principle, this concept is great, but the amount of features a remote offers is going to be hard to replicate using a number of gestures that an older person can memorize. They will probably be even less incentivized to do this (learning new things sucks) if they already have a solution (remote), even though they really love you. I'm just warning you.
I recommend you use OpenNI and NITE. Note that the current version of OpenNI (2) does not have Kinect support. You need to use OpenNI 1.5.4 and look for the SensorKinect093 driver. There should be some gesture code that works for that (googling OpenNI Gesture yields a ton of results). If you're using something that expects OpenNI 2, be warned that you may have to write some glue code.
The basic control set would be Volume +/-, Channel +/-, Power on/off. But that will be frustrating if she wants to go from Channel 03 to 50.
I don't know how low-level you want to go, but a really, REALLY simple gesture recognize could look at horizontal and vertical swipes of the right hand exceeding a velocity threshold (averaged). Be warned: detected skeletons can get really wonky when people are sitting (that's actually a bit of what my PhD is on).

real time refreshing in processing

I am new to processing, i found it by searching for "draw with coding" , and i tried it, seems every time i modify the code, i have to stop and render again to get the final result
Is there any way to get updated graph without re-rendering? that can be much more convenient for creating simple figures.
if not, is there any alternative to processing that can draw a graph with coding?
I've used Tikz in Latex, but that is just for Latex, I want something that can let me draw a figure by coding, I've suffered enough though using software like coreldraw, it lacks the fundamental elegance of coding..
thanks alot!
Please have a look at the FluidForms libraries.
easy to setup
documentation and video tutorials
as long as you don't run into exceptions, live code comfortably
if you prefix public variables with param you also get sliders for free :)
Do check out the video tutorials, especially this one:
Also, if using Python isn't a problem I recommend having a look at:
NodeBox
Field
Python is a brilliant scripting language - which makes prototyping/'live coding' easy(although it can be compiled and it also plays nicely with c/c++) and is easy to pick up and a joy to use.
In Processing, you must re-run your program to see the changes (graphically), unless you write code to receive input from the user to dynamically adjust what you are drawing. For creating user interfaces there's for example the controlP5 library (http://www.sojamo.de/libraries/controlP5/).
It doesn't support "live coding" (at least that I know of).
You must re-run the code to see the new result.
If Live coding is what you're looking for, check out Fluxus (http://www.pawfal.org/fluxus/) or Impromptu (http://en.wikipedia.org/wiki/Impromptu_(programming_environment)

How do I write an panel task bar in FLTK for use on Linux systems

I need to write a small application in C/C++ to implement a panel task bar like thing to display information along the top of a desktop window (specifically an xorg desktop on a Linux system). I need to avoid bloat and steep learning curves for the GUI programming.
My research is pointing me at GTK+/GTKmm or FLTK. It looks like FLTK is probably the simpler to get to grips with and the most likely to provide a small clean package with minimal dependencies. So I've based my research on FLTK so far.
I've been doing some reading and am struggling to find out how to write a basic program that will create a narrow undecorated window that covers the width of a monitor in such a way that maximising other applications would not obscure it. The FLTK tutorials I have found so far (including the FLTK documentation) only implement standard windows with borders that can be moved around the screen.
I'd like to start by writing a simple program in FLTK (or GTK+/GTKmm) that creates a 20 pixel deep bar across the with of the screen containing a "hello world" message. The bar's area would be reserved outside the area that other programs can access so that maximising another application would not hide the "hello world" message. I think this has something to do with a WM_STRUT_PARTIAL property but I can't find information about this in FLTK.
Doing this is partially to understand how to write a simple GUI program and partially to solve a specific need that I have.
I'm looking for any help/guidance to put me in the right direction to get started. Many thanks.
starfry, it is not a trivial task I believe. The problem is that your desktop (say GNOME2/Metacity) reserved that space, and paints its panel in the area where you want your bar. -
If you really want your tray-bar applet to be based on FLTK, the you would have to "embed" it in a (GNOME) applet. It was long ago when I did similar thing with SDL application, but I am afraid I forgot how to do it. The first thing that comes to my mind is to use somehow get the XID from the GNOME applet and somehow pass it to the FLTK part of it, and then let FLTK do the rest...
Sure, you may use another desktop, like KDE, or i3 or IceWM, they ALL have their own ways of dealing with the tray bar (there is no standard for it!) so, pardon my "French" - it is going to be a PITA to support all environments...
If I was on GNOME, i would write the applet entirely using GNOME/GTK. Forget FLTK in that case. That is my recommendation. If you target KDE, then do it using KDE/QT libraries (Plasma widget would be what to look for).
However, if you still want to use FLTK, start with the fltk::draw_into() function (it is probably called fl_draw_into() in FLTK 1.x), fltk::xid() and related functions.

VB6 Game Development

I am developing a game in VB6 (plz don't ask me why :) ).
The storyboard is ready and a rough implementation is underway.
I am following a "pure-software-rendering" approach. (i.e. no DirectX, no openGL etc.)
Amongst many others, the following "serious" problems exist:
2D alpha transparency reqd. to implement overlays.
Parallax implementation to give depth-of-field illusion.
Capturing mouse-scroll events globally (as in FPS-es; mapping them to changing weapon).
Async sound play with absolute "near-zero-lag".
Any ideas anyone. Please suggest any well documented library/ocx or sample-code.
Plz do suggest solutions with good performance and as little overhead as possible.
Also, anyone who has developed any games,
and would be open to sharing her/his code would be highly appreciated.
(any well-acknowledged VB games whose source-code i can study??)
UPDATE: Here is a screen shot of GearHead Garage.
This picture ought to describe what i was attempting in words above... :)
(source: softwarepod.com)
EGL25 by Erkan Sanli is a fast open source VB 6 renderer that can render, rotate, animate, etc. complex solid shapes made of thousands of polygons. Just Windows API calls – no DirectX, no OpenGL.
(source: vbmigration.com)
VBMigration.com chose EGL25 as a high-quality open-source VB6 project (to demonstrate their VB6 to VB.Net upgrade tool).
Despite that, and despite my opinion that VB6 is often criticised too harshly, I can't help thinking there must be better options for game development in 2010?
You may want to check out the Game Programming Wiki -- it used to be "Lucky's VB Game Site" (and we're talking a LONG time ago) but all of the content (VB5/6 centric) moved to the Wiki with the addition of other languages.
It appears that much of the legacy VB6 content is still available on the site.
Have a look at DxIce : http://gamedev.digiapp.com/
I think you will find no well-acknowledged written games in VB6 for precisely the reasons you state above.
It was not designed to be a high performance language. For that you NEED to use the graphics libraries (DirectX, OpenGL) you said you didn't want to use unless you want to BitBLT everything yourself using API calls which is probably not going to get what you need.
VB6 is interpreted, outdated, and I'd be surprised if it runs on Windows 7.
I think you need to seriously re-evaluate the methodology here.
For audio playback, I have used http://www.fmod.org/ in the past. This, and other libraries like BASS, are only free for non-commercial use. I also suggest avoiding the built-in multimedia playback object.

Major game components

I am in the process of developping a game, and after two months of work (not full time mind you), I have come to realise that our specs for the game are lacking a lot of details. I am not a professional game developper, this is only a hobby.
What I would like to receive help or advices for is this: What are the major components that you find in games, that have to be developped or already exists as librairies? The objective of this question is for me to be able to specify more game aspects.
Currently, we had specified pretty much only how we would work on the visual, completely forgetting everything about game logic (AI, Entities interactions, Quest logic (how do we decide whether or not a quest is completed)).
So far, I have found those points:
Physics (collision detection, actual forces, etc.)
AI (pathfinding, objectives, etc.)
Model management
Animation management
Scene management
Combat management
Inventory management
Camera (make sure not to render everything that is in the scene)
Heightmaps
Entities communication (Player with NPC, enemy, other players, etc)
Game state
Game state save system
In order to reduce the scope of this queston, I'd like it if you could specifically discuss aspects related to developping an RPG type of game. I will also point out that I am using XNA to develop this game, but I have almost no grasp of all the classes available yet (pretty much only using the Game component with some classes that are related to it such as GameTime, SpriteBatch, GraphicDeviceManager) but not much more.
You have a decent list, but you are missing storage (save load), text (text is important in RPGs : Unicode, font rendering), probably a macro system for text (something that replaces tokens like {player} with the player characters name), and most important of all content generation tools (map editor, chara editor, dialog editor) because RPGs need content (or auto generation tools if you need ). By the way have links to your work?
I do this exact stuff for a living so if you need more pointers perhaps I can help.
I don't know if this is any help, but I have been reading articles from http://www.gamasutra.com/ for many years.
I don't have a perfect set of tools from the beginning, but your list covers most of the usual trouble for RUNNING the game. But have you found out what each one of the items stands for? How much have you made already? "Inventory Management" sounds very heavy, but some games just need a simple "array" of objects. Takes an hour to program + some graphical integration (if you have your GUI Management done already).
How to start planning
When I develop games in my spare time, I usually get an idea because another game lacks this function/option. Then I start up what ever development tool I am currently using and try to see if I can make a prototype showing this idea. It's not always about fancy graphics, but most often it's more about finding out how to solve a certain problem. Green and red boxes will help you most of the way, but otherwise, use Google Images and do a quick search for prototype graphics. But remember that these images are probably copyrighted, so only use them for internal test purposes and to explain to your graphic artists what type of game/graphic you want to make.
Secondly, you'll find that you need to find/build tools to create the "maps/missions/quests" too. Today many develop their own "object script" where they can easily add new content/path to a game.
Many of the ideas we (my friends and I) have been testing started with a certain prototype of the interface, to see if its possible to generate that sort of screen output first. Then we build a quick'n'dirty map/level-editor that can supply us with test maps.
No game logic at this point, still figuring out if the game-engine in general is running.
My first game-algorithm problem
Back when I was in my teens I had a Commodore 64 and I was wondering, how do they sort 10 numbers in order for a Highscore? It took me quite a while to find a "scalable" way of doing this, but I learned a lot about programming too.
The second problem I found
How do I make a tank/cannon fire a bullet in the correct direction when I fly my helicopter around the screen?
I sat down and drew quick sketches of the actual problem, looked at the bullet lines, tried some theories of my own and found something that seemed to be working (by dividing and multiplying positions etc.) later on in school I discovered this to be more or less Pythagoras. LOL!
Years and many game attempts later
I played "Dune" and the later C&C + the new game Warcraft (v1/v2) - I remember it started to annoyed me how the lame AI worked. The path finding algorithms were frustrating for the player, I thought. They moved in direction of target position and then found a wall, but if the way was to complex, the object just stopped. Argh!
So I first sat with large amounts of paper, then I tried to draw certain scenarios where an "object" (tank/ork/soldier) would go from A to B and then suddenly there was a "structure" (building/other object) in the pathway - what then?
I learned about A-star pathfinding (after solving it first on my own in a similar way, then later reading about the reason for this working). A very "cpu heavy" way of finding a path, but I learned a lot from the process of "cracking this nut". These thoughts have helped me a lot developing other game algortimes over time.
So what I am saying is: I think you'll have to think more of:
How is the game to be played?
What does the user experience look like?
Why would the user want to come back to the game?
What requirements are needed? Broadband? 19" monitor with 1280x1024?
An RPG, yes - but will it be multi-user or single?
Do we need a fast network/server setup or do we need to develop a strong AI for the NPCs?
And much more...
I am not sure this is what you asked for, but I hope you can use it somehow?
There are hundreds of components needed to make a game, from time management to audio. You'll probably need to roll your own GUI, as native OS controls are very non-gamey. You will probably also need all kinds of tools to generate your worlds, exporters to convert models and textures into something suitable for your game etc.
I would strongly recommend that you start with one of the many free or cheap game engines that are out there. Loads of them come with the source code, so you can learn how they have been put together as you go.
When you think you are ready, you can start to replace parts of the engine you are using to better suit your needs.
I agree with Robert Gould's post , especially about tools and I'd also add
Scripting
Memory Management
Network - especially replication of game object states and match-making
oh and don't forget Localisation - particularly for text strings
Effects and effect timers (could be magical effects, could just be stuff like being stunned.)
Character professions, skills, spells (if that kind of game).
World creation tools, to make it easy for non-programmer builders.
Think about whether or not you want PvP. If so, you need to really think about how you're going to do your combat system and any limits you want on who can attack whom.
Equipment, "treasure", values of things and how you want to do the economy.
This is an older question, but IMHO now there is a better answer: use Unity (or something akin to it). It gives you 90% of what you need to make a game up front, so you can jump in and focus directly on the part you care about, which is the gameplay. When you run aground because there's something it doesn't do out of the box, you can usually find a resource in the Asset Store for free or cheap that will save you a lot of work.
I would also add that if you're not working on your game full-time, be mindful of the complexity and the time-frame of the task. If you'll try to integrate so many different frameworks into your RPG game, you can easily end up with several years worth of work; maybe it would be more advisable to start small and only develop the "core" of your game first and not bother about physics, for example. You could still add it in the second version.

Resources