Skip to main content

News

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - N E O

31
Site Comments / [FORUM] Increased storage
I received a notification that the attachment's folder is almost full, so I decided to increase its numbers. Posts can now take up to 5 attachments instead for 4, each attachment can be up to 256 KB instead of 128 KB, and per-post attachments can total up to 512 KB instead of 192 KB.

Don't go crazy with it now, and do please still try to optimize image attachments before uploading, thanks!
32
Game Development / Beaker's games (for study & play)
For those who don't know, Beaker is a Sphere user and developer from back in the day (even before me!). He has a degree in mathematics and he knows his stuff. While his last post on this incarnation of the Spherical Forums was about his most recent game Emergency Riot Response, he has made games in Sphere for far longer and has previously added to custom Sphere engine builds basic 3D graphics functionality, movie playback, and Wiimote capabilities.

He currently hosts his games on RPGMaker.net and certainly has plenty of variety from which to choose. These games should also be found on the Spherical Downloads Repository as well and range from platformers like Jack and Turbie to the Risk-like Warriors of the Sword and the puzzle game Entropy. The games in this list are complete and should be playable from start to finish with any vanilla Sphere 1.5 distribution (except Cheesohol which requires the Wiimote-capable custom build included with it, and maybe one other game) and certainly demonstrate a taste of what Sphere is capable of.

On my request he has uploaded a couple of his classic, but incomplete, games Larium and Resorsis to http://rpgmaker.net/users/Beaker/locker/ as I've found that more often than not when a new user is interested in a Tactics-style game we almost always point to Beaker's work for its practical and relatively quick implementations of basic pathfinding and RPG stat and inventory integration. According to Beaker, both Larium and Resorsis require old versions of Sphere to run; Resorsis specifically was made for Sphere 0.92a, which had support for MIDI files, and those would likely have to be converted in order to run on vanilla 1.5, while Larium has "spriteset alignment problems with the latest version of Sphere (works ok, but looks off)" but is said to run properly in Sphere 1.0, and "you can use compatibility mode with win98/me to get that to work." Both Larium and Resorsis should also now be found on our Downloads Repo.

There is one more game of Beaker's that I often mention when recommending his work for study: The Rainis Manuscript, a 3D Final Fantasy Tactics-like game, is, according to him, still in development but is not officially available for download. At one point a long time ago it was available for preview but no longer; instead he has made available to those who'd like to study similar techniques a tech demo Turbie's Super Fun Happy Hour. It can be found on an archived version of his old site, http://www.oocities.org/spherebeaker/ , and should be found on our Downloads Repo as well.

Ed.: For those studying programming techniques, Beaker's code is not for the faint of heart. It is recommended to get acquainted with reading and understanding other people's code first before diving into the extremely mathematical and spartan scripts of a Beaker project. Earlier works (especially Larium and Resorsis) are known to use raw numbers for array lookups instead of named properties and JS object construction for things like an RPG party member's stats or an item's common properties. It gets the job done, but even if the code's spacing is clean it's certainly not pretty. Recommended for those who want to and are ready to learn advanced mathematical techniques that can be directly applied to games in Sphere (or even game development in general) and are comfortable with reading someone else's code.

(edit: added note about Cheesohol custom engine ~neo)
33
Game Development / Code.org and visual programming
So code.org, a website whose goal is to teach programming visually, apparently celebrated a birthday. For it, they have a "Flappy Birthday" tutorial on creating a Flappy Bird clone with code.org's visual editor and it's pretty good; apparently I finished it in less than 10 minutes and now have a weird, very randomized Flappy clone of my own.

Would there be any interest in a visual editor for Sphere similar to how code.org does it? It looks to generate standard JavaScript in the background and attaches preset behaviors via the visual editor, though I wouldn't be surprised if they have some sort of library to which they offload the heavy lifting like Three.js or something (I haven't dived into the code yet for analysis).
34
Projects / Flappy Sphere
Follow the progress of Flappy Sphere at https://github.com/sphere-group/sphere-projects !

So yea, Flappy Bird has come and gone and now there are no shortage of clones, including a couple of HTML5 ones. I am going to port the one from flappybird.io (basically identical to the one from freeflappybird.org; don't know which was first and which was the copy) to Sphere as a personal exercise to see how dull my Sphere-specific development skills have actually become. I don't currently know if I'll attempt to use the map engine or not, but it'll certainly be playable.

My goal is by the end of the weekend, but if needed I'll take a full week or so on it. My main development goal is to rein in my tendency to currently over-engineer things, so we'll see how it goes.

MISSION START!
35
A recent series, it's mostly focused on making JS games for the web but most of the principles can likely be ported over to Sphere usage. I came across it from the recently updated Gorenfeld pseudo-3D rendering article and Jake Gordon (aka Code inComplete) created a basic JavaScript racing game on the web using it.



Some secondary links from the articles:



Now, Jake's the first to say that his recommendations shouldn't be taken as bible or even as best practice (he himself points out in the JS Racer series that his JS isn't even close to ideal or the most optimized), but at least it's a good jumping-off point for getting the systems needed ready to go once the basic game design is worked out.

I personally wouldn't mind seeing that JS racer forked and modified enough to work in Sphere ;)
36
I'm a huge fan of byuu's nall library (latest version is in the latest higan release). It has made my C++ programming exponentially simpler and has proven to be significantly lighter weight in my programs than std equivalents. In its very robust string parsing capabilities is code for parsing text as markup, specifically XML and byuu's own BML. It's missing a JSON parser, however, and I wanted to write or port one for byuu to add to nall proper.

I've been having a devil of a time getting myself organized about it :(  Initially I started by porting SuperEasyJSON to nall syntax but I kept getting error after error. Then I decided to start over and attempt to replicate the API found in nall's existing parsers (found in the nall/string/markup directory) but the inconsistency between how XML is parsed and how BML is parsed results in me unable to choose one or the other to use as a jumping off point.

How should I go about writing a JSON parser for nall? Every instinct I have says "parse one character at a time" but I would love to take advantage of nall's existing functionality, especially with regards to node iteration and value conversion, and Unicode inside JSON strings is supported and that would be annoying to handle alone even with this unicode_to_utf8 function.
37
Game Development / RPG JS & RPG Creator for reference
RPG JS
RPG Creator

Assuming RPG JS is any good (especially the Canvas Engine stuff of the guy), do we want to use its design as a possible base for implementing Web Sphere? A quick look at its source on GitHub reveals a design paradigm (extremely modular and, probably by the necessity of using JS for the core, extremely functional) that's significantly different from the current ways we already implement Sphere (monolithic as fuck, extremely intertwined, and extremely procedural in most instances) and I'd like some opinions from others here on whether it's better or worse.
38
Programming / Wu Lines - better than Bresenham!
An article and pseudocode implementation for Wu Anti-Aliased Lines, a fixed/floating point implementation of a line drawer from a Michael Abrash book:

http://freespace.virgin.net/hugo.elias/graphics/x_wuline.htm

I use it for my line function in my open-source phoenix tutorial app!

39
Sphere General / Future of Sphere: SGM v2 and beyond
As recently as this post in the TurboSphere thread the limited ability of the current SGM format has come into question and once again discussion of extending it has arisen. I agree that the existing format is limited and vanilla Sphere 1.5 doesn't even allow keeping manual edits!

The main topics at hand are the text format of the file (with the most popular choices being XML, BML, and retaining its current INI style), what per-game settings would be stored, and nomenclature for those settings.

Each text format has its pros and cons, with INI style having the primary advantage of being backwards compatible with current implementations of Sphere (unhandled settings being ignored in forks and in vanilla Sphere once that bug is fixed and pushed). BML is fairly custom but easily parsed. XML is XML.

Continue the discussion in this thread!
40
Off-Topic Discussions / My site is finally updated!
I've finally finished the redesign of my site! I left it alone for a little over 5 years and I'm proud to say I've updated it to be modern.

http://www.luxatom.com/
41
Projects / Sample phoenix project
https://github.com/apollolux/hello-phoenix

Hello world-style project using phoenix to make a simple project. Compile with `make`, or `make platform=windows` (formerly `make platform=win`) on MinGW.

@Flying Jester - let me know if this is useful for you, thanks!
42
Game Development / JS Full Screen Mario
site (while it's still up), github

It's Mario! On your browser! In JavaScript+HTML5! And open-sourced!

While according to the Reddit thread it's already been C&D-ed by Nintendo, it's meant as a completely editable Mario-style platform engine and the main reason the creator used Mario is to show people it was possible. In the project's GitHub issue tracker he says he can always replace the media resources used if/when Nintendo jumps on him.

MEANWHILE: THIS would be exactly what we could use (minus the Mario resources) as the platforming tech demo for Sphere if we could get it sufficiently edited as such.
43
Site Comments / SourceForge
Sphere's SourceForge site is now once again accessible! Its forums, on the other hand, seem to generate a PHP error and I haven't yet turned on display_errors so I don't know what the problem is (I'm assuming some deprecated functionality being used or something SF's hosting might now block with mod_security or something).

Downloads section is accessible, though the links are likely external so YMMV regarding success of retrieval. Wayback Machine might help in that regard, and it might behoove us to put anything there we can DL onto the Repo under an "Old Resources" subfolder or something.

Most sections seem to be accessible, though I'm of the mind that any white-page results are due to unhandled PHP errors from the old CMS software. I may turn off new registrations and re-purpose it as archives once a decision can be reached regarding how to best use SourceForge for Sphere's purposes in this modern web.
44
Programming / Using byuu's nall/phoenix libraries on MinGW
nall and phoenix are abstraction libraries written in C++0x by byuu, the author of the bsnes & higan emulators. nall is meant to be an STL replacement, while phoenix is meant to be a GUI abstraction library that uses as native an API as possible. On Windows, phoenix will compile with Win32; OS X will use Cocoa; Linux will use GTK+2 or Qt4 depending on what the desktop environment is.

Compilation customarily uses GNU Make and is optimized for it. Simply write your Makefile similar to the following:

Code: [Select]

ifeq ($(platform),)
platform = unix
ifeq ($(shell uname -a),)
platform = win
else ifneq ($(findstring MINGW,$(shell uname -a)),)
platform = win
else ifneq ($(findstring Darwin,$(shell uname -a)),)
platform = osx
endif
endif

# platform
ifeq ($(platform),unix)
include Makefile.unix
else ifeq ($(platform),osx)
include Makefile.osx
else ifeq ($(platform),win)
include Makefile.win
else
unknown_platform: help;
endif

# You'll need to customize your own help label
help:;


...and you can put all the OS-specific stuff in Makefile.win, Makefile.osx, Makefile.unix, and any other Makefile.* you wish to write. Below is a sample Makefile.win that should work with compiling a nall/phoenix project on Windows using MinGW+MSYS:

Code: [Select]

# point these variables to the directory locations on your system relative to your project
PH  = ./phoenix
NALL= ./nall
OUT = ./out

# APP is the filename (without extension) of your app in question; there should be a file named $(APP).cpp in the project's folder
APP = trk
BIN = $(APP).exe

# standard helper files;
# in bigger projects the "ui" directory would contain the phoenix code to create the interfaces,
# the "formats" directory would likely contain the nall code to load/save file formats
CXXFILES_WIN = $(wildcard ui/*.cpp)
CXXFILES_BASE = $(wildcard *.cpp)
CXXFILES   = $(CXXFILES_BASE)
HEADERS_FMT = $(wildcard formats/*.hpp)
HEADERS_WIN = $(wildcard ui/*.hpp)
HEADERS_BASE = $(wildcard *.hpp)
HEADERS = $(HEADERS_FMT) $(HEADERS_WIN) $(HEADERS_BASE)

# any necessary libraries; include SDL here, for example
LIBS =

# any necessary flags; include SDL cflags here, for example
FLAGS =

# the required libraries to compile on Windows; you can remove -mconsole here with it if you don't plan to write to STDOUT
WIN32_LIBS = -mwindows -mconsole -lkernel32 -luser32 -lgdi32 -ladvapi32 -lcomctl32 -lcomdlg32 -lshell32 -lole32 -lshlwapi

# use top line if you have a phoenix GUI, the bottom line if you don't
OBJ      = $(DIR)/resource.o $(DIR)/phoenix.o $(addprefix $(DIR)/, $(CXXFILES:.cpp=.o))
# OBJ      = $(addprefix $(DIR)/, $(CXXFILES:.cpp=.o))

WINDRES  = windres
CXX      = g++
RM       = rm -f
DIR = $(OUT)

# force 32/64-bit compilation if you define ARCH on your `make` command line
ifeq ($(ARCH),32)
FORCE_ARCH = -m32
FORCE_WIND = --target=pe-i386
DIR = $(OUT)32
BIN = $(APP)-32.exe
else ifeq ($(ARCH),64)
FORCE_ARCH = -m64
FORCE_WIND = --target=pe-x86-64
DIR = $(OUT)64
BIN = $(APP)-64.exe
endif

CXXINCS  = -I"$(NALL)" -I"$(PH)" -I.
CXXFLAGS = $(FORCE_ARCH) $(CXXINCS) -std=gnu++0x -DPHOENIX_WINDOWS -g $(FLAGS)

.PHONY: all clean

all: mkout $(DIR)/$(BIN)

clean:
$(shell if [ -d "$(DIR)" ]; then $(RM) -r "$(DIR)"; fi)
$(RM) *.o

mkout:
$(shell if [ ! -d "$(DIR)" ]; then mkdir "$(DIR)"; fi)

# build phoenix; comment out if not using phoenix
# resource.rc is a standard Windows-format resource file and app.ico in "res" directory is the app icon
$(DIR)/resource.o: resource.rc res/app.ico
$(WINDRES) $(FORCE_WIND) $< $@
$(DIR)/phoenix.o: $(PH)/phoenix.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

# build app
$(DIR)/%.o: %.cpp $(HEADERS) $(CXXFILES_WIN)
$(CXX) $(CXXFLAGS) -c -o $@ $< $(LIBS)
$(DIR)/%.o: %.cc
$(CXX) $(CXXFLAGS) -c -o $@ $< $(LIBS)
$(DIR)/$(BIN): $(OBJ) $(wildcard res/*.png)
$(CXX) $(FORCE_ARCH) -s -o $@ $(OBJ) $(LIBS) $(WIN32_LIBS)


byuu himself provides most of his projects in source form and the latest ones (higan v093, beat v03, and mosaic v07 at the time of this writing) should have the latest versions of nall and/or phoenix included. If you still need help, view the source and makefiles included in those projects.
45
An extension to the topic of built-in "transcompilation" I started, I expect that if community consensus leans in favor of adding such capabilities down the line that the topic of using other scripting languages in general would inevitably be raised again. This thread, therefore, is anticipation of such and I highly recommend taking part in the transcompilation discussion first before this one as the two are related but this would likely need to build off that first.

In the future, do we want to expand the Sphere engine's capabilities to properly allow other scripting languages to be used within the engine?

Besides adding the full-on scripting environment(s) in question, barriers to this proposition would include implementing Sphere's specific API (or a reasonable facsimile thereof) in said language(s) and the loading of Sphere formats (which is probably the easier of the two).

Python specifically seems to have a gaping hole with PyGame not being updated since 2009 and ika not since 2010 (its last ppa update was for Ubuntu Maverick Meerkat; can an Ubuntu user confirm whether its corona and audiere work for Sphere on Ubuntu?), but both communities are still rather strong which says to me Python is a popular scripting language for game development. I haven't done the research on Ruby or Lua, but RPGMaker is still among the most popular commercial game development systems and still uses Ruby, and Lua has been used even by "AAA studios" for "AAA games" (including Street Fighter IV).

I'm not explicitly saying we should recreate ika, RPGMaker, Love, or another existing engine with separately updated scripting languages; they have their own APIs that are likely not one-to-one with Sphere's and their formats are also not directly binary compatible with Sphere's (though the latter can probably be resolved with simple converters).

There's probably other factors in play with such a decision as well. This is the topic for such discussion.