In other news, this sickness is back and is rough. But if something good has come of it, it has led to taking a couple of health measures:
Drinking fire water. This stuff is just great generally, but especially if you are not feeling well. To make, in a tall glass add.. a squeezed lemon a swig of apple cider vinegar a minced garlic clove a little honey a few pinches of salt a good dose of powdered cayenne pepper You can add whatever else you prefer at this point optionally; it could be warm vegetable broth or a little barley green or ginger tea or some squeezed grapefruit juice, etc. Fill the rest of the glass with warm water while stirring gently.
Trying to keep on the B and C vitamins, too, and staying away from needless stress. Also, this monitor is positioned more ergonomically now, and there's a solid pillow in this chair.
Been sick for a couple of days, but felt better today - whew.
Pride in your shell scripts is a bit like a builder showing off his scaffolding. Still, since it's the frame of mind I've been in most recently when tinkering with this project, here is my make-installer batch file. It uses the NullSoft Installer System (NSIS) and 7-Zip. Instead of registering each file with NSIS, it directly copies the directories, and it must tell the NSIS script what size the installation is so that it can know the correct size to display during the installation. The one downside with not registering each file with NSIS, it seems, is that the installation progress bar doesn't move very smoothly during the installation process, instead jumping from a low level to full. If redoing it, it might be preferable to inject files individually or use some other method, but it doesn't really bother me; it's just a little Windows installer.
rem ///////////////////////////////////////////////////////////////////// rem //WARNING! DO NOT DISTRIBUTE THIS INFORMATION! rem /////////////////////////////////////////////////////////////////////
set POIESISLICENSEGENERATOR=xxxxxxxxxxxx set POIESISUSERNAME=Dan Nielsen set POIESISUSERROLE=Developer
rem INITAL READ-WRITE ATTRIBUTE SETTINGS attrib -r poiesis\TEXT\main.c echo Initial read-write attributes set echo. rem pause echo.
rem INITIAL CLEANUP del \\School-2065a8c5\SHARE\RELEASE\poiesis.zip /q del poiesis\OUTPUT\*.* /q del poiesis\bin\*.pdb /q del poiesis\bin\*.exp /q del poiesis\TEXT\main.c /q if not exist poiesis\bin\cyan.exe goto skipRewriteMainExecutable del poiesis\bin\poiesis.exe copy poiesis\bin\cyan.exe poiesis\bin\poiesis.exe del poiesis\bin\cyan.exe :skipRewriteMainExecutable echo Initial cleanup performed echo. rem pause echo.
rem SETS LICENSE INFORMATION echo License generator of this machine: cmd\rlmutil.exe rlmhostid -q -ether echo. src\licenseMaker\Release\licenseMaker.exe %POIESISLICENSEGENERATOR% %POIESISUSERNAME% %POIESISUSERROLE% copy license.c+init.c+update.c poiesis\TEXT\main.c echo License information set echo. rem pause echo.
rem SETS VERSION INFORMATION copy README.template.txt poiesis\README.txt cmd\change.com poiesis\README.txt "REPLACE.VERSION" "%POIESISVERSION%" echo. echo Version information set echo. rem pause echo.
rem SETS INSTALLATION SIZE INFORMATION IN KILOBYTES cd poiesis for /f "tokens=*" %%a in ('"dir /s /-c | find "bytes" | find /v "free""') do @Set summaryout=%%a rem echo %summaryout% for /f "tokens=1,2 delims=)" %%a in ("%summaryout%") do @set filesout=%%a&set sizeout=%%b rem echo %filesout% rem echo %sizeout% set sizeout=%sizeout:bytes=% rem echo %sizeout% set sizeout=%sizeout: =% cd.. copy poiesis.template.nsi poiesis.nsi cmd\change.com poiesis.nsi "REPLACE.SIZE" "%sizeout:~0,-3%" echo. echo Installation size information set echo. rem pause echo.
rem FINAL READ-WRITE ATTRIBUTE SETTINGS attrib +r poiesis\TEXT\main.c echo Final read-write attributes set echo. rem pause echo.
rem BUILDS INSTALLER cmd\makensis.exe poiesis.nsi echo Installer built echo. rem pause echo.
rem MAKES ZIP PACKAGE AND PLACES IT IN SHARED DIRECTORY cmd\7z.exe a \\School-2065a8c5\SHARE\RELEASE\poiesis.zip poiesisInstall.exe poiesis\ echo Compressed and placed installation package echo. rem pause echo.
rem FINAL CLEANUP del license.c /q del poiesis.nsi /q del poiesisInstall.exe /q del poiesis\README.txt /q rem del poiesis\TEXT\main.c /q echo Final cleanup performed echo. rem pause echo.
And the following is the NSIS .nsi file, mostly just ripped from an example included with the NSIS package:
; The name of the installer Name "Poiesis"
; The file to write OutFile "poiesisInstall.exe"
; The default installation directory InstallDir $PROGRAMFILES\Poiesis
; Registry key to check for directory (so if you install again, it will ; overwrite the old one automatically) InstallDirRegKey HKLM "Software\Poiesis" "Install_Dir"
; Request application privileges for Windows Vista RequestExecutionLevel admin
Page components Page directory Page instfiles
UninstPage uninstConfirm UninstPage instfiles
; The stuff to install Section "Poiesis (required)"
; MUST CHANGE THE FOLLOWING TO SIZE IN KILOBYTES!! AddSize REPLACE.SIZE
; Set output path to the installation directory. SetOutPath $INSTDIR
[font="arial, verdana, tahoma, sans-serif"][size="2"]Here I'll give a brief description of the project I've been working on most recently. It's called Poiesis. Since its very infant release ca 2 weeks ago (Windows: http://www.mediafire...rpqwzkedlbp3elx), it is a utility for allowing a user to create various specialized fonts very easily and then to type a few lines in them. As it develops, it will be able to do other handy things to allow users to develop their own creative content and to link it together. Poiesis is all 32-bit fixed-point (except that it makes use glut and fmod, but I've rewritten the base class so many times to make use of different libraries, I'm not doing that again until it makes sense).
Within a few more releases, I wish to support very flexible text styles, including combined characters, variable character widths and kernings, text that can run along any defined path and various orientations (like upside-down and inverted) and various looks (eg "carved wood", "painted stencil", "quill pen", "crumpled paper"). Also, I'd like users to be able to chat in their various invented scripts.
There are many other things I hope Poiesis will do, and some of these features may call for implementation first, depending on the development path chosen. For instance, once the basic graphic script features are implemented, it might be nice to do something similar for all the basic audio-related features, or perhaps it would be better to polish one system piece first. Chances are, due to time constraints, I'll often wind up dealing with the system component that seems most doable at the time.[/font]
Yesterday was my first day of tutoring a student in C & C++ online. I'm still figuring out the best methodology for all of this. I've taught various students in various subjects over the years, and have found that schedules can easily get out of hand. If anyone else is looking to go down this road, I'll just mention a few perhaps rather obvious but important tips.
1) Find out the goals of the student. Be careful that you are not just performing homework assignments. This won't be good for you, the student, and everyone else involved, while it may be easier for you. I am still trying to figure this part out. How can you completely trust that any goal the student puts forth is not current university classwork, or that they are not being paid to supply answers for another class? I don't know. Whatever instruction path you take, have at least a general lesson plan. Find out if the student will be able to uphold their end of the deal; eg are they planning on using a TI-80 or some obscure IDE?
2) Have everything in writing. Create a good contract that specifies everything that will happen, including what is expected of the student and what is expected of yourself. If terms & conditions change, document this. Think carefully about loopholes and so-called Acts of God. Document how communication will take place between you and the student. If possible, make a voice recording of the student agreeing to terms & conditions. Don't get yourself stuck in a long-term contract that you cannot uphold. If the student has extenuating circumstances - eg health issues - the time to consider them is now. Consider also how much time you allow for the student to show up. Myself, I feel that it is the student's hour, so I am allowing h/h to show up at any time during that hour. Might need to rethink this, though, if it becomes problematic. If you or the student are remote desktopping, there are security issues to consider as well.
3) Require payment first. Specify how this payment will be made and for what. Remember that payment processing fees may take money out of your pocket. Don't make payment the only issue, though, or you might come off sounding untrustworthy,
4) Follow up. Think about it from the students' perspective; you've just told them that you can perform a somewhat specialized service if they pay you money first. The more you let them know that you have a schedule and a life, the more you will appear a real person. With the crazy life I have watching my 2-y-o, I have to make certain that professionalism is maintained as well.
5) Watch your time. Don't overextend. The more you do, the more will be expected and the less professional you may appear. But do uphold your end of the deal to the best of your ability, and communicate well in writing. (Also, remember that your student may be in another time zone.)
If anyone else is pursuing something similar, please let me know. I'd sure like to trade notes as this goes along.
Tomorrow I'm going to be performing a screen share with someone, and I was embarrassed by the state of the desktop on my old XP test machine. Mostly due to that, I more-or-less organized all the files on that computer, so I'm happy but don't have much to share tonight.
However, I did have another Windows duh moment. I should have known that Windows XP has built-in ClearType support, but didn't realize it until I stumbled across the option. If you aren't familiar with ClearType, it's just Microsoft's brand of subpixel antialiasing, which makes text look better, especially on most full-sized LCD displays. Maybe everyone knows this already or they don't use XP any place, but, since it made me a little happier, here's how to enable ClearType in XP:
Control Panel > Appearance and Themes* > Display > Appearance tab > Effects... > "Use the following method to smooth edges of screen fonts: ClearType"
[font="Helvetica, Arial, sans-serif"][size="2"]Every once in a while it is worthwhile to step back and take a look at easily remedied inefficiencies. Here is a setup change I only just made, but which will be used a great deal. Maybe it could be handy for someone reading this.
It's annoying in Windows to access the command prompt from the start menu, and then to cd to the needed directory. Instead, it's nicer to right-click on a folder and select "Command prompt" to jump right there. To do something like that is simple in the classic Windows menus, of course:[/font] [font="Helvetica, Arial, sans-serif"] [/font] [font="Helvetica, Arial, sans-serif"] [/font][font="Helvetica, Arial, sans-serif"][size="2"]Windows Explorer > Tools > Folder Options > File Types tab > "Folder" type > "Advanced" > "New" Then enter.. Action: Command prompt Application used to perform this action: C:\WINDOWS\system32\cmd.exe[/font] [font="Helvetica, Arial, sans-serif"] [/font] [font="Helvetica, Arial, sans-serif"][size="2"]Alternatively, if you are a little more brave about it, you could also do this:[/font][font="Helvetica, Arial, sans-serif"] [/font] [font="Helvetica, Arial, sans-serif"] [/font] [font="Helvetica, Arial, sans-serif"][/font][font="Helvetica, Arial, sans-serif"][size="2"]From the command prompt, type "regedit"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Open HKEY_CLASSES_ROOT[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Open "Folder"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Right-click on "shell" and select "New">"key"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Name it "Command prompt"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Right-click on it and select "New">"key"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Name it "command"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]Open "command" and double-click "(Default)"[/font] [font="Helvetica, Arial, sans-serif"][size="2"]For value data, enter[/font] [font="Helvetica, Arial, sans-serif"][size="2"]C:\WINDOWS\system32\cmd.exe "%1"[/font] [font="Helvetica, Arial, sans-serif"] [/font]
Okay, so this is a little bit of a schizo stroll in which I'll be talking to myself aloud, because this is pretty much the only time today I've had thoughts to myself.
Recently I've been using a C-based script in my projects. I have been very happy with the consistency of having my main project in C++ and the script in a similar style. Data files, however, were treated differently. They are divided into folders as TEXT and MEDIA. MEDIA includes typical large binary file types like .bmp, .wav, .avi and their similar compressed counterparts. TEXT includes all other, typically smaller, data files. My approach here was to use relatively standardized file formats that could easily be read by both human (hence "text") and computer.
I noticed that much of the data in TEXT tended to be either superfluous or not exactly what I wanted. As well, I thought it would be nice to have all of the initialization data in a single file. After all, the main program script was in a single file. One other thing was that a user editing the TEXT data files might not have a clue what data ranges are supported for listed variables. It seemed a good idea to require explicit types. And we may as well use double slashes for comments, since they are used in the other code. Basically, I decided to place this data into a C-like data declaration format (no, not a markup language). Let's call this data initialization file script.h, and let's call the actual script code script.c.
Now for the babble aloud part of this post..
The naive approach here would be to check within the main C++ code for the variable names mentioned in script.h, then to load in the associated data in the proper manner based on the particular case.
But wouldn't it be nice instead to use the same variable names in script.h as those that are used within the main C++ code? It would be consistent, and then one would not need special cases; one would simply create new variables in the C++ code, and then use the same variable names in script.h. What is needed here is a way of automatically generating the cases based on declaration string matches in the files. But I despise generated code. Does this mean build time will take noticeably longer?
Okay, instead I'll think preprocessor directives and macro functions for registration of variables.. later.
Hey, free dev log & a much faster site - nice job, GameDev!
Okay, so I've broken the images from my old posts; well, maybe this will prod me into upkeeping a web server again, for consistency's sake.
Hope all are well. Perhaps I'll just begin by describing a little about my views on Linux. Basically, I see Linux and its accompanying GNU libraries and applications as this all-absorbing pit of anguish that from time to time floats down from the heavens to devour bits of my soul and optimism. That's not to say I dislike Linux, GCC, Eclipse, X Windows, etc; it's just that they IME tend to increase time for many projects ported from Visual Studio. Your mileage may vary, and I certainly give that they are better for certain applications. And free and open source is great for such critical system components (not for applications in general, though, IMO).
Oftentimes old, heavy machines get passed along to those who need a computer. Sometimes one is called upon to make these old mares dance. The system disc is always gone and it's never worth buying a copy of Windows for these things, so installing Linux seems a foregone conclusion, assuming the HDD and other components are in decent shape. Luckily most users only want to play music, video, surf the web, write documents, and play a few games. Anything you do beyond this is essentially wasted effort - actually, worse than wasted, because you may accidentally negatively affect those core experiences.
There is nothing difficult about setting up Linux in this day and age, except that it still can easily become like a flowchart beginning with a box 1 labelled "Install Linux" and with every arrow pointing back to box 1, while the arrows represent headaches, embarrassment, and lost sleep. After the initial installation, one may be tempted to do logical things like install the latest graphics drivers, install various programs based on their installation instructions, perhaps search out some obscure software that you believe will be up the alley of the user. If working with an old machine meant for someone "not really into computers", I would advise again these things. Instead, here are simple instructions for getting a lot out of little effort, and maintaining your smile.
--Download Ubuntu and install it. Ubuntu fits on a single CD, whereas some distributions have expanded to a DVD. Ubuntu's Gnome desktop and menus look clean and are easy to understand. The distribution includes basic applications, like the OpenOffice core, but not much else.
--Open a terminal window and type the following without quotations: "sudo apt-get install rpm" "sudo apt-get install libboost*" "sudo apt-get install build-essentials" "sudo apt-get install gxine" "sudo apt-get ubuntu-restricted-extras" "sudo /usr/share/doc/libdvdread4/examples/install-css.sh" "sudo apt-get install gimp" "sudo apt-get install pingus" "sudo apt-get install wormux" "sudo apt-get install frozen-bubble" "sudo apt-get install lbreakout2" "sudo apt-get install xpenguins" This will install a few components, including some games, their associated libraries, and a more robust movie player.
--Place a movie DVD in the drive. When asked which application to use to run the DVD, select "custom command" and type the following: gxine -f
--From the menu, go to "System">"Administration">"Users and Groups" and set up the other users.
There are plenty of other routes to a clean, simple, stable but useful OS on an old computer, but maybe this will save somebody a little searching.
In keeping with the theme of human affliction, pestilence, conflagration, and the like that has touched some of the development notebooks lately, I'll just say that I spent the last week out of town because April was in need of medical attention. There is a lot going on at the moment.
Not the least of which is searching for a work-from-home job. Could anyone share some advice on finding telecommute opportunities? Moving to another location could be acceptable, but work-from-home is prerequisite as of now. I have found more available genuine openings than I would have guessed, but would be so grateful for any advice. My special interest is development for mobile devices. Most of my current codebase is in C++.
For many years, I've wanted a 32-bit FPGA RISC SOC with a little on-chip RAM, bus, and controllers. Something like a Microblaze. Also, I'd like this attached to a 640x480x16b LCD and a 16b audio system. I'm just putting this out there, in case anyone hardware-minded might be interested in fusing their interest and will to such a project (while including me).
I previously sent a couple of motivations for this project to Falling Sky:
->Minimal For a mobile device, it is nice to have minimal hardware, minimal production costs and complexities, and minimal power consumption. Putting an entire system on a chip would be a good way to do this. I am interested in making a CPU that holds all the system RAM on the CPU chip for faster access and less power. It might only need about 2MB on-chip total (+ external graphic/audio/network/etc RAM). Maybe more, depending on the OS and the program. While it would most likely have a flash drive, in theory, I could see all programs being downloaded "from the cloud" (or whatever you'd like to say).
->Reconfigurable Well, I'm wanting something I can reconfigure and run my programs on. Being anal retentive, I would also like it to be the bare minimum hardware on which the program could run. Eventually, it might be fun to try to program specialized hardware functions or architectures, or to have the device try to reconfigure on the fly. Mostly, I'd like to make sure it at all times has the preferred screen, sound system, and input system for the project.
When I say "I", I don't mean that I want control over the direction of the project. I'm just telling you what my current goals would be. The HDL I have experience with is VHDL. I currently live in Huntsville AL.
I made first-round changes to my previously submitted article. Looks like it will be on GameDev! I really was not expecting much in the way of feedback, just a boolean, "That'll work", or, "Improve submission". What came back instead was an in-depth breakdown from Gaiiden [Rev: From the staff editor c/o Gaiiden] that helped me to communicate a few points more clearly.
Last week, all graphic functions in my library were reimplemented in 16-bit color mode, which is now the default color mode. The memory savings is substantial for this system, which can also diminish needless complexity and power on mobile devices. Mainly, 16-bit rendering will allow programs to be run on actual current real-world mobile devices, not just imaginary emulated ones. So what do I have to show for this work? Slightly less-detailed graphics! Oh well, cel shading is still the rage, right? A scheme might be added in the future to perform a little edge blur through dithering, but it is probably not needed.
Also, single-buffer graphics were dropped completely - a no-brainer - though I was proud of how much I'd managed to do with a single buffer, and had thought there might eventually be a way to perform some interesting VRAM minimization for specialized devices. For the script commands and for hardware specification, it seems better to predetermine what memory is available where and for what - hence only one available screen buffering mode.
We're taking a trip to Bitville. If you don't care for the place, you may want to hop off now.
Recently I have fortunately had a little time to sit and think, but very little time to code. This is a dangerous situation for code-crafting junkies, because we will begin to optimize and redesign everything that we don't like in our own weird way - the calendar, power waste, our shoelaces - but the actual physical creation that many people might realistically adopt from us, deservedly or not - our program - can become either an unkempt, piecemeal Frankenstein creature or merely an atrophied icon of a useful system. The situation does place a premium on efficiency, though. For this reason, it may become very exciting to read about some little thing that can be performed quickly to better our code, and that will retain its value and reusability.
Luckily, I ran across just such an article, written a couple of years ago by Nils Pipenbrinck (http://www.devmaster.net/articles/fixed-point-optimizations/). Pipenbrinck gives some good information on compilers and integer math (although in most cases there is really no need to use long integer casting as he does, and I don't know that CLZ-based looping for a square root on a 32b input argument would be worth the cost of overhead and unpredictable timing - minor questions).
Another recommendation is to visit the Dark Bit Factory, if you haven't (http://www.dbfinteractive.com/index.php). The showcase is fun, and I love that it gamuts everything from tight Asm to Basic. I will definitely be pulling a quick-shot idea from somewhere in that place. (I think I'm beginning to sound like Junie B Jones.)
I was also searching for some information from Jacco Bikker, who had written some handy bit-twiddling articles several years ago. I didn't find much, but did link from one of his tutorials to a 2001 survey paper on raytracing. The part that caught my attention was about progressive, corrective rendering:
"Recently, Haber et al have extended the approach to include perceptual information: This is used to focus the sampling effort towards perceptually important regions, thus getting visually pleasing images in less time. Corrective information is no longer stored in textures, but is splatted directly into the image. Here too, the image quality improves progressively as more and more corrective samples are computed..." (Wald & Slusallek, 2001)
It reminded me how little information really changes between each frame. If you take the average difference of two consecutive frames, I'd guess less than 5% of the graphic information has changed. Yet we render the entire scene again and again. There is so much our stereoscopic understandings pull out of small details in an image, so we cannot afford to mess them up. Additionally, each scene may be drawn with its own rendering scheme, constructed with its own primitives, and given its own special T&L, so it is difficult to define how we might conserve resources but still render a convincing 3D scene without redrawing everything in the window. All this caused me to reappreciate how nice interlacing really is for methods that can use it. It also inspired an experiment that I plan on trying out shortly.
I submitted an article to GameDev! Title: "Dynamic noise" [Rev: now "Moving noise"]. I'm hoping it doesn't get rejected, because I like it. And, you know, that would feel not so good. But then I'd make lots of copies of my article on toilet paper rolls and install them everywhere I went. Afterward I'd hack GameDev by posting to the forum and replying to my post, like, four times in a row.
Where'd I go? I'd say everywhere, but you don't get there in a broken car - well, unless its on a barge or something. (Supposed to purchase a car today, but the financier didn't return our calls. Let's try again in Tomorrowland!)
[I just noticed a line about a recent security breach or something on GameDev - hope it didn't seem like I was making light of that.]
Currently adding 2D rigid-body collision detection and response. There are a few different types of 2D sprite game that I hope to support through the script with a common data structure and method. This could take some time.
Downloaded some ambient sounds from whitenoisemp3s.com. If you have any reason to drown out noises, then you might like to use them at home. I have nothing to do with their production - just cropped the edges so that they can be looped.
The flu's been pretty rough these last few days, so I haven't done much, but did take out some features that won't be useful enough to upkeep in the game I'm working on, and improved a couple little bits.
Now I'm using set-pixel methods to do special graphics processing, instead of performing a final screen-processing pass. It's working well. The main motivation for this was that I often want to use single-buffer screen mode, so I can't draw and then post-process the screen. Also, this will allow portions of a scene to be processed individually. The vertical inversion won't be done this way, though, due to the inefficiencies involved.
Mainly, I'd like to show a couple of scans I made from my sketchbook, to which I did a little touchup, adjusted the monochrome threshold on the sketch, then added a background and some rough shading.
It is necessarily taken for granted but nonetheless incredible how we perceive the light structures around us. Although cultures around the world can perceive color differently (the Japanese do not emphasize the distinction between green and blue, for instance), color tends for humans to be linked more to basic biology than to culture.
As such, color is a subject that is core to the history of scientific observation. Whether measuring the movement of stars or the transitions of electrons, the color of visible light is historically our first way of estimating what is going on - and perceptually what to attend to within our static range of vision. In line with this statement, optical measurement devices show an elegance all their own. A prism is a marvelous device for performing a very fast Fourier transform. Simple optical fibers carry color for miles. So much information can be extracted from each "chunk" of light that surrounds us, and photons themselves can act and interact in wonderful ways.
Big deal, you must be saying by now. Why am I going on as if I am writing an overexcited introductory school paper? If I want to talk about integer pixel colors on a computer screen, it's pretty simple, though the screen settings may vary.
True, but color is the fundamental way we communicate with the game player, and there are many standards. Last spring, I hacked up a little catalog in Basic code to consider a few of them.
The other day, I almost lost my mind and wanted to swap many program functions over to paletted mode, if only because the ablility to manipulate color so easily through an LUT would be handy. 24b linear-scale color just has too many benefits for that, though.
What I did do was to add a rendering pass for rotating pixel hues in RGB space over the entire screen. I think I first found the algorithm about ten years ago on Grafica Obscura (http://www.graficaobscura.com) and am surprised to see that that is still the only place I have managed to find it. Converting the algorithm to an efficient reduced integer form gave a challenge, due to my misinterpretations of the way the transform functions operated in this code, mistransposed matrices, and forgetting to bound. Who would have guessed it takes 7 elementary matrix transforms to form this color rotation matrix? (Hmm, an interesting notion for an application in psychology comes to mind.) Still tinkering with scaling, but I think (hope) it's working right.
This extra rendering pass adds quite a bit of processing to each screen draw, but I think it's worth it. It is certainly more efficient than trying to perform color functions during the main rendering pass. At the same time, I could convert color depth to whatever the screen handles. Also, as a kludge, perhaps the program could invert the screen during this pass, to fix my DirectDraw Mobile problem. Still not entirely sold on the idea of this software rendering pass. Maybe even devices that don't support complex graphics hardware could at least support a color transform in VRAM. Still, these software color functions will always prove their utility for certain routines - and can be modified in the future.
A couple of days ago, while trying to decide on the best and most reusable way to write some programs, I had a conception of what would be my ideal script interpreter. At first it didn't appear to be something in which a person could write a complete, fun game, but now I think it's possible. It won't be a game-specific script, though. This process of making a script has really crystallized the significant parts of each program method and their parameters.
Audio scripting works with some various capabilities. Now to graphics. You might think that simple graphic functions like blitting would be the easiest portion to code. That would be true, until thinking about all the various ways that even straight-blit graphics are used - in single-buffered or double-buffered mode, layered in various combinations, sometimes read from a file straight to the frame but other times read or manipulated off-frame, where ideally they should be tightly packed together and maybe even compressed. Then there are all the conditions associated with choosing the optimal blitting routine and carrying out special blitting functions. I should have expected complexities, though; after all, even 1D audio presents more challenges than it displays.
Creating the network commands later. Asked my old prof for permission to use our little cluster at his school to test the net scripting. Then there's input. If this script is going to support mobile devices, input specs will need to be designed with that in mind.
I've been trying to prepare a little library over the past few days, along with a couple of websites. After I knew what I was doing, I thought it wouldn't take much work at all to transform my code into a DLL, but it took a bit more wrangling than I thought. In the process, I dropped support for Windows-with-GL and Windows GDI modes due to the upkeep hassle, leaving only glut and DirectDraw Mobile modes.
Still facing two very inane issues with running this library on the Windows Emulator under Windows Mobile 6. I state them here in hopes that someone may offer assistance..
->Both fmodce.dll and my own library DLL are not being found by the emulator (but my program runs when not implementing DLL files). Or at least that's what I believe the problem is. I receive the unhelpful message "Specified module could not be found". Have tried placing the DLL files in various directories after searching for other linked libraries. Have also tried using Dependency Walker.
->The screen is upside-down, due to the DirectDraw drawing convention. From what I've seen, DirectDraw Mobile does not have built-in vertical inversion (http://social.msdn.microsoft.com/Forums/en-US/vssmartdevicesnative/thread/b9b7a741-f09f-44ba-921f-4a3981d66920/).
Please assist with this, I plea! I don't want to put out upside-down screenshots!
It's very likely this article exposes my lack of knowledge about current games in play, but it seems relevant from my experience. I'm using the term adventure-action to differentiate the subject game from games considering themselves action-adventure, which might be any game with any story at all.
1984 STILL KNOCKING ON THE DOOR
I was scanning the Chris Crawford "Art of Computer Game Design", published all the way back in 1984, and currently found here.. http://www.vancouver.wsu.edu/fac/peabody/game-book/Chapter3.html
I noticed that Mr Crawford in the above text classes adventure games as "puzzles", not games. My first reaction was acceptance of that statement, if puzzles are to be considered in a separate class from games. Then came deciseconds of confusion. Then, How darest thee! Adventure "games" are most certainly games, as they are so involved and immersive, personal and interactive, and strive for a wide range of personal input from the player. The designer has combined various story elements in layered and interesting ways. Then I realized what was very obvious: from a mechanical classification, adventure games are always just a prebuilt puzzle. You can choose your own adventure, but you can bet in most any adventure game out there, there is always a clear ending that has been traced out by the designer. When the common adventure game player thinks of alternate-path adventure games, that person won't think much of late-golden-age graphical adventures, but more of the early games, like Black Cauldron, where it didn't take so many resources to craft each available ending. If there is a difference in the cauda of a late-golden-age game, it is usually, "Go back and collect what you missed". Responding to improbable player input could be viewed as responding to unexpected path taking, but that happened mostly in text-based adventures, less in point-and-click adventures, and was always a simple gameplay branch crafted by the designer. Theoretically, however, a certain level of computer AI could handle unexpected statements in a way unimagined by the game designer. That would require the system to be fairly good at relating symbols.
Scanning backward through the Crawford text, I noticed bizarre statements classing race-and-avoid-obstacle games, which most would call "action games", as puzzles also: "One problem with all of these games is that they are not true games but puzzles, for there is no real interaction in a race between a player and his opponent. Indeed, it is difficult to identify the opponent in these games."
So, that writer does consider this issue a "problem", as these games do not involve an apparently important goal in game design: "real interaction between the player and his opponent". I would agree that racing against obstacles is not very personal; even though a designer may be very creative in designing obstacles, most just fly by quickly or shoot at the main actor. Aside from that, however, what constitutes "real interaction" to an audience is fairly variable in real life: some may believe they have real interactions with sharks; others may see them as nothing but obstacles no matter what events occur.
Scanning further backward.. "A game acknowledges the player's existence and reacts to the player's personality; a puzzle lies down like a dead fish." Okay, that is definitely a pejorative.
The whole issue leaves me trying to find the right "out", as I intend to create an adventure-action game. Adventure games are important in the same ways that books and movies may be important - but they trade the high polish of an entirely preassembled sequence of words or images for that of a dynamic sequence. (Although you can pause a movie, play it backward, or watch it upside-down while talking to yourself, it is still intended for the general audience to be watched one way.) The player is involved in accessing their own abilities to interact with a story. In any adventure, the action elements are important, because the player can experience another way of thinking and acting. It breaks up the monotony, and immerses the player in the world, showing a new dimension - often, literally, a new physical dimension - to experience in that world. I think of entering the arcades in Space Quest and actually playing the games in that setting, where the games evolve as did those in our real world: Astro-Chicken, Ms Astro-Chicken, Stooge Fighter.
So let's sum up the Crawford criticism of the two separable parts of an adventure-action game: ->Adventure's problem is that it is too constrained to the designer's will. ->Action's problem is that there is too-little personal relation to an opponent. An adventure-action game is by these definitions bipolar - too controlled by the mind of the designer, but at other times too impersonal and lacking in depth.
My argument, first, is that all entertainment truly belongs to its creator. The adventure game designer had an idea that was important to the designer, and so helped to create a game to link those images in an immersive way. One could consider every movie out there to be a bad movie for the same reason - it's too constraining as a form of entertainment. But movie viewers are willing to trade the independence of their thoughts to see where the experience will take them. Viewers may then talk about the movie in a common frame. Adventure games do not deliver the same experience to each player. They reward those who figure out the puzzles the same way that the creators envisioned. A movie, like all popular static art, rewards those who consider the movie's most generally accepted interpretation to reflect their own experience of the symbolic network related to the movie. But it really presents no challenge at all to the viewer. There is no requirement for engagement. A well-crafted puzzle requires attention and cognitive investment. It can pay back greater rewards as player resources are invested.
Your car was designed by someone else to operate in a certain way. A car doesn't care that the sunshield hits your face, or that it was designed for the average Japanese body, or that it will carry around 5 extra seat spaces when you're driving alone. It basically gets you where you want to go and knows that, in the end, you'll be grateful (if the car works). That is like a movie. Linear devices obviously have their purpose. I would be happy if all cars were made by the government using the same parts, but came in a couple of sizes. They'd be cheaper and more reliable. I'm not saying movies should be made that way, however (although some are). Where was this going?
Hopefully making more sense on this and related topics in a post to come..
Added #define statements around some code blocks to make them optional to compile, and now adding a method to blit the background image fullscreen, 256-color paletted, and stretched. The best part is, I can use the 1MB (inverse) z-buffer to store the background image, since this is a nonocclusional game, and reuse it during 3D segments! That gives 2048x2048 as the ideal resolution for the stretched background image - that's just the right background size for good gameplay, I'd guess! (If you like specialized functions, then this is a good example of why it is best to write your methods as you use them.)
There really is not much at all to the physics of this minigame, but still I am reading up a little to refresh on the Verlet method.
Coding game physics in general can be an all-consumptive process, so these days I'm preferring to keep my eyes on task, and to follow the game design plan. I remember assembling before me the Chris Hecker articles on rigid-body mechanics - spending so many hours figuring out what it all meant, drawing out huge matrices, putting together a general rigid-body physics simulation, setting up input files, editing LinPack, and cleaning up compile issues. At the end of the process came the realization that, try as I might, there is really no good use I could come up with for ragdoll physics in a game. This was at the same time that a certain physics engine claimed to have secret, novel, and more-stable algorithms for doing all these things in 3D. Around that time, I was deciding to eschew floats completely from my code anyway. Ever since it's been only simple wham-bam physics and completely active character control for me. If there's an inexpensive or freely available integer-based dynamics library that works well with my primitives, I will probably use it and like it, but for now I'll stay away from all general-purpose high-precision engines until given a reason to do differently. Server-side physics might enter the creative domain eventually, but hopefully not.
I should now have a solid block of two protected hours per night to work on development projects, without stealing from the sandman. I'm happy about that.
I have created the background image for my minor game from a couple of images I found on the web and edited. I really like it.
Also, I have been using OpenMPT to create my first .xm files. It has been such a joy. I noticed Trapper used it, so it seemed like the right thing to do. Yes, the .xm created is repetitive, brief, and not the most ambitious or original-sounding tune in the world, but I think it sets the right mood. Thank you, freesound.org.
The software library I've written over the past years includes a simple procedural synthesizer along with a simple music string parser. (Think of the "play" statement in Basic, except with the ability to change tracks, instruments, and volume settings.) In writing the synthesizer functions, my most useful sources were the Andy Farnell website (http://obiwannabe.co.uk/tutorials/html/tutorials_main.html), a tiny speech synthesizer included with the digital magazine Hugi 24, and the Karplus-Strong algorithm. I have very minimal requirements of sound, so I have read far too much information in the meantime on sound processing. Convincing the unfatigued ear is all that matters - "just do whatever works" has been my lesson.
An idea came last night for a simple minigame. I wanted something fun that might pull together quickly. It is nice to have a light at the end of a tunnel, so that work may be developed in a double-ended process, concentrating on what one is doing and what one would like.
I won't describe the project in detail quite yet. There's only a spare hour or so in each weekday for me to work on personal development projects, so it is sure to come out very rough. Polish may come later, if the game gives enough enjoyment. In fact, the entire game "skin" might change. Right now the game is set in free-float outer space (inside a giant spaceship). That can be pretty boring due to the lack of integration with environmental associations and constraints, but the interesting part (or so I think) of this game is the mechanic, which doesn't seem to work out as well in any other setting that I've tried.
Joel Davis' current GameDev article "Better Programmer Art" inspired me to do some image-making. I could really relate to his section on pixel-pushing; I've gone down that path too often. This is a graphic design of dolphins that came to me a couple of months ago. I constructed it today using GIMP and some sealife photos found on the web. Although the image could use polish, I think it really works. I expect elements will appear through some incarnation in my game.
Here are other strange sealife (or seadeath) I've run across recently that might be suitable for game character ideas.. ->Spookfish http://news.softpedia.com/news/The-Spookfish-039-s-Vision-Is-Based-on-Mirrors-not-Lenses-100845.shtml ->Mimic octopus http://www.advancedaquarist.com/2007/4/fish ->Manta Ray skeleton http://files.tellmewhereonearth.com/Photos%20Sharks/gordon76.JPG
Here is some email correspondence I've had over the past couple of days that seemed fruitful. It regards the problem of event paths in games. (The message begins with a remark about an Ernest Adams article from 2006 that is not meant to be unduly disparaging.) It uses the vocabulary and phraseology of Goffman dramaturgy. (More common computer terms may be "agent" for "actor", "world" or "ecology" for "setting", etc)
As a related question, what games would you think of as offering the player direct control over the game world event probabilities? I think mostly of Cube 2: Sauerbraten, that allows the user simple tools for dynamically changing the world in a constrained way - or maybe of Second Life. I should warn, I have not played many of the games out there. So it would be especially interesting to know.
[dwn] This is sort of bootleg psychology, but I was reading the following article on believable events in games.. http://www.designersnotebook.com/Columns/082_Ken_Perlin_s_Law/082_ken_perlin_s_law.htm
The article basically applies the Laplace principle that "the weight of evidence for an extraordinary claim must be proportioned to its strangeness".
In this case a game player can expend a "credibility budget" to buy "weight of evidence" for weird actions, but eventually the budget will run out, so the player's actions will be constrained to the "believable" path. The example used is, if the game mechanics allow it, the actor could materialize a chicken out of thin air, but then the actor will not be able to perform many other bizarre actions in the game world.
This does not appear to be a very good approach, however, because it does not take into account the event path (although it does constrain the player to acting within the available game mechanics). In other words, the actor might materialize a chicken out of thin air, but now the player will likely consider the actor to possess some magical abilities - and will actually expect the actor to behave more oddly in the future, not less. The actor has jumped to a different position on the field of potential actions. If the credibility budget slowly replenishes, the player might wait to spend it on one incredible action, or might spend it little by little for more believable actions.
Each action impresses a different understanding of the actor upon the player. If the player causes the actor to act magically whenever possible, the actor will be a magician. This is related to the Heise affect control model, which updates an impression formation matrix for each observer every time an event occurs. The goal of the actors is to maintain their Evaluation-Potency-Action placement as defined by their role and their emotional state. Role and sentiment are the sort of the gravitational law that keeps the events on the believable path, and emotion is the response to events in the setting.
One small point about this model is that each event is discrete, and therefore each movement on the event "river delta" is actually a quantum leap. An interesting question would be, Is this the best approach, or might there be some sort of wave-based impression memory system to suit this model?
The person who wrote that article initially given above is pretty well known in the field of game design, and if he has not seen this sort of thing implemented, it probably has not been done well. Just wanted to write down and share these thoughts.
[awm] Did you recognize that Ernie assumed a duality relation to express his "ah ha" experience as to how to balance player freedom and designer freedom? I especially liked how you tied this to Heise's impression formation matrix. For Idyl, this cost function plays out on different grains of analysis. One of the obvious grains is in the affordance-effectivity coupling.
I reply, though, to point the way toward an answer to your question of how to deal with the discrete, greatest-lower bound on event costs. The mathematical probability approach to this has been worked by a researcher named Minsky. He formulated a probability amplitude description of the event path ("river delta") to express the probability cost for a particle's particular state value along the path. I believe with a little work, you and I could calculate a corridor.
Thanks for sharing this article with me. I want to work further on this with you.
[dwn] Thanks for the quick reply - Yes, now that you put it in the framework of decision theory, the idea doesn't sound at all novel - except, as you point out, when tied directly to affect control and impression formation. Maybe what gives the article the exciting veneer, besides the intimate style it is presented in, is the idea that the probability of events is dynamic and may be changed by the player, not only the designer of the game, although the integrated change cannot exceed a constant. That is very specific. Controlled randomness, as with Perlin noise or simluated annealing, shaped by the art of the player.
In actuality, the probability of events should change in less predictable ways every time the player makes some action. The impression formation matrices of all players would change, and thereby also the probability that the main actor can perform actions to maintain affect control (credibility). So there is that complicated chicken-and-egg duality occuring between impression formation (perception) and event probability (action). Whether the player can effectively reflect these complicated dynamics, or whether this should be left to the designed game mechanics, might be in some way quantifiable.
I will start finding out what I can about Minsky. I would really like to work on these topics with you. If we came up with specifics, it could all boil down to a mathematical model that anyone could program (although it would be nice to have some sort of adventure game interface around it).
[awm] Clarification on the second paragraph requested please. Why/what constraint were you considering when you wrote that with each next player perception-action cycle (pac) would change toward a less predictable (lower probability) event?
My inclination is to allow the change in probability density to be non-directional. The change in likelihood would be a function of how relevant the player's next state is to the player's intended state (i.e., goal path) or, in another case, how relevant the player's next step is to the designer's intended state. This would allow a graded determinism on the shared cost function between the player and designer. For example, if the player's pac path was far from the designer's pac path, then the probability amplitude corridor (a quantum probability operator) would reduce the likelihood of that particular player's pac (loose-shift). If on the other hand the player's pac path was near the designer's goal path, then the probability operator would increase the likelihood of the player's pac (win-stay). The probability would be a multiplicative weight that gauged the player's experience of freedom (hence a graded determinism).
Here are some references. I now realize I miss spelled Mensky's name. The way I sent it to you below confuses the issue with Marvin Minsky.
Continuous Quantum Measurements and Path Integrals by MB Mensky (1993) Advances in technology are taking the accuracy of macroscopic as well as microscopic measurements close to the quantum limit, for example, in the attempts to detect gravitational waves. Interest in continuous quantum measurements has therefore grown considerably in recent years. Continuous Quantum Measurements and Path Integrals examines these measurements using Feynman path integrals. The path integral theory is developed to provide formulae for concrete physical effects. The main conclusion drawn from the theory is that an uncertainty principle exists for processes, in addition to the familiar one for states. This implies that a continuous measurement has an optimal accuracy-a balance between inefficient error and large quantum fluctuations (quantum noise). A well-known expert in the field, the author concentrates on the physical and conceptual side of the subject rather than the mathematical.
Mensky's teacher I believe, Quantum Measurement by Vladimir Braginsky (1995)
This work is known as non-demolition filter theory. The formalism also trace back to the BRDF and the BSSRDF out of the Stanford computer graphics group. You showed me Henrik Jensen's work and then another person's work we've discussed, Eric Veach (http://www-graphics.stanford.edu/papers/veach_thesis/). I've worked this problem on the information/perception side of the path formulation.
[dwn] Hmm, that sort of credible-path gutter seems to be what Ernie is doing. A preset, constant credibility budget will let you go a constant distance from the credible path, but then no further. So that is a walled gutter. Or that would be the case, except that 3 things (that I can find) are changing: the setting (events possible in the scene), the perceptions of the other actors (materializing a chicken may not even be noticed by a hypnotized actor), and the perceptions of the main player (who may consider her actor to be a magician now that she has seen the actor materialize a chicken).
Going back to the walled gutter analogy, we might instead think of the credibility budget as a string attaching the main actor state to the credible path; the string can go out so far, but then must stop, or the system breaks. We might also consider a spring analogy, where one wants the main actor's actions to be so far off the credible path, but not too far, so that you push and pull them. That might be sort of a double-gutter, with some sort of hysteresis determining which side the player falls on (I'm thinking the "dark side or light side" kind of story). Alternatively, the story may be more like a skier going over moguls, getting kind of pushed this way or that, with the path not entirely determined until the end. Or maybe somewhere in between, like many staggered gutters. I guess it is up to the resources and aesthetic determinations of the game creator.
Wow! I would really like to check out those books. I will try the library at your university, if I can ever get a moment to go outside. I don't want to take up all your time, but thanks for continuing to correspond with me on this!
Here I am in a little electronic heaven, fulfilling this longtime desire for a developer notebook on Flipcode - I mean, Gamedev. Herein will reside a compilation of whatever game-development material seems noteworthy. Really, I am good at getting off-topic, but will at least try to form some superficial connection to gaming. That's the plan, man. And I'd hope that, in the process, I can give back a little to GameDev, the site that has nutured our compulsions and creative impulses for so long.