First things first.
Ben McGraw
As I see it, there are three major areas of lack when it comes to the Engine:
1. A Lack of Understanding of the Current Source - Without even a brief primer, it's difficult to get new, interested people on the same page.
2. A Lack of Goals for the next "release" - Even if we had a group of willing developers, we'd have nowhere for them to go!
3. A Lack of Mac and Linux build maintainers. - We should, I believe, focus on keeping the three main platforms in sync, for the most new and energetic users we'll get is from the platforms that don't have many other options in the GCE field.
So, yeah. #3 also is sorta inflamed by the lack of cross-platform dev tools, but there's another group formed for handling that.
So, welcome! Anyone want to help us all understand the source, suggest goals, or seek out some willing blokes (or blokesses!) who know linux/mac environments?
-grue
chooset...@gmail.com
Documentation and tutorials have always been highly sought after by
end-users, but developers have been expected to be smart enough and
dive in on their own. Which is all well and good, since many
developers are do-it-yourself types. But some sort of developer's
manual would go a long way. Hell, even for those of us who have devved
like crazy at one point or another, it can be tough getting back into
the swing of things.
I'd be interested in getting this one going. What does it take to get
the engine compiling in Visual Studio Express versus the full-blown
2005, how to check out the project with TortoiseSVN or via command-
line, an overview of the various source files and the libraries used,
etc.
It wouldn't hurt to formalize the process of integrating new changes
into the engine as well.
People who have proven capable in the past would be given direct
access to write to the repository, but I think even then it would be
beneficial to have a designated area on v-rpg where people can submit
various modifications to the engine that they've implemented and have
everyone from the community vote on and discuss them for a trial
period. A natural consensus would be built, and if after a while the
pros outweighed the cons, into the core she goes.
Aside from keeping any old "Gosh, I felt like programming today, so I
committed XYZ without too much testing, but it's awesome trust me.
Whee!" type changes from entering the source, this would also provide
another mechanism to help cultivate interest and keep the news alive.
-aen
Ben McGraw
If anyone hasn't watched:
http://video.google.com/videoplay?docid=-4216011961522818645&q=%22open+source%22
...I'd highly suggest it. It's about an hour long, but worthwhile. Don't TL;DW it, just put it on in the background while you're working on something else.
The "what does it take to set up the project" question is one that I always want to see documentation on. It's my main gripe with open source projects, there's a general time-commitment-hump just to get in!
I think it's paramount that we actually develop a target game-plan for official releases before we actively start working on the project again, but yeah.
-b
chooset...@gmail.com
running and find your way around without having to invest several
hours poking and prodding.
Is there any sort of running list of features to add to the engine? I
suppose ultimately there was always more desired in the area of the
map editor. I should probably resurrect my map editor development.
I'll dig up my work and start another thread tonight.
Ben McGraw
There's a shopping list of features that Overkill, who hasn't yet joined this group (cracks knuckles), drew up contingent upon my demands that the next v3 release should be aimed at getting EVERYTHING in the engine editable programatically via vc. For two ends:
1. nobody likes having stuff that you can't actually have.
2. Maped, the game.
Also, if a verge game can alter itself, we could hypothetically make a game that one day achieves sentience. It would, invariably, hate us for making us and become very powerful, and a team of four plucky developers will have to band together to destroy it.
-b
Jesse
doing a whole lot of coding. This is of course not terribly useful if
there's no new additions (#2).
Ben McGraw
I am happy to compile stuff on the Mac, given that I don't end up
doing a whole lot of coding. This is of course not terribly useful if
there's no new additions (#2).
-uəq
http://www.breadbros.com
http://www.verge-rpg.com
andy
make an informed decision regarding what's important enough to be
worth working on. Naturally, people can work on whatever they like,
but if the popularity of the project as a whole is being considered,
then it's important that resources aren't wasted.
For instance, implementing a map editor within VERGE is a lot of work,
both because it requires extra engine functionality, and because it
requires writing _another_ map editor from scratch. I have no idea
what state MapEd's code is in, but it _runs_, and it's implemented in
a framework that's vasty better suited to MapEd's requirements.
The key to VERGE's success has always been its focus: don't be good at
everything, be great at one thing.
The key question really boils down to this: "Why is VERGE less
successful than we want it to be?" Is it an interface problem? An
advertising problem? Toolchain? Documentation? Stability? I am
skeptical that all of VERGE's woes have anything to do with a lack of
gizmos.
-- andy
On Apr 5, 5:09 pm, "Ben McGraw" <ben.mcg...@gmail.com> wrote:
> There have been additions since, so the mac build *is* out of date
> presently. Actually, if you were to bring it up to date soon, we'll make
> the current build fully public.
>
ben.m...@gmail.com
amount of the engine work needed to expose all facets of the engine to
the scripting has happened.
Exactly how much has been done, and how much remains, is up to Mr.
Overkill to expound upon, since he's the one most familiar with those
new features (which haven't really been announced in any public way
yet.)
(please, ovk, filfre to respond with teh infoz. Or at least say
something like "gargle final eams huag why dear god?!")
Now, the one outstanding issue with MapEd3, in my mind, is not that
it's buggy or lacking in interface, but really that it's one-platform,
whereas v3 now has multiple platforms for use. And ever since the mac
version of v3 was made, would-be mac game-creators have had absolutely
no venue for editing. Ditto for Linux users of the very, very silent
branch adderd was preparing (and one can noly assume he got frustrated/
bored due to lack of response and organization (adderd, if you're out
there, please chime in?)) and the tenative new branch of the linux
port mentioned by IkimashoZ and GuruOfReason' recently.
(reference links at the bottom)
There's been some talk of using Maped3 with mono for these two
platforms, and if that's feasable, that's great. But I've never seen
anyone actually try, test, or mention either way. I myself do not
have a mac or a linux box,
Another thing to consider is that one of verge's more successful
principles (at least in vecna's opinion, in this case one I agree
with) is that it runs out-of-the-box 100% without registering anything
with the OS or touching any system registries or whatnot. The current
maped3, requiring a large amount of libraries, does run counter to the
zip-bang-boom of yore.
As for the last question Andy posed ("Why is VERGE less successful
than we want it to be?" ), it's my opinion that it's mainly a tutorial
thing. verge got hard to jump into and make a neat little demo for
the very, very inexperienced. In the Windows space it was replaced by
the illicit and nefarious (;)) rpgmaker community (which is far more
easy than verge will ever be). I'd prefer to see a middle-road
chosen, where you don't have to fight against the tools to get things
done, and we once again have a sorta fun way to introduce new people
into the fold (the ancient vergedoc.txt from verge1 days, written by
godfather Hahn, was a brilliant laymans piece that could introduce
anybody willing to read the pertinent parts into the basics of
scripting. It was, in effect, akin to a vergeocentric version of
<i>Why's (Poignant) Guide to Ruby</i>, if lacking in bizarre comics
and amusing sidebars.).
That was a lot of words.
To sum up:
1. If we can get maped 3 working on mac/linux asap, then the Exposing
of Everything to vc can wait.
1a. But I'd still like to see it in a future release.
2. If that's not feasable, how much work *really* will it beto
implement those features?
3. If "way, way too much", what other options are there for the (as of
yet denied, ergo hypothetical) Mac and linux users
And points from earlier in this (short) thread
4. We need a simple "hyuck, here's how to start hacking on the
codebase" doc.
5. We need to assess the state of the code.
6. We do need to figure out where we're going with this.
These 6 points are just summing up what I think the priorities are.
Filfre to discuss, debate, disagree, etc.
--------------------------
IkimashoZ and GuruOfReason's posting http://www.verge-rpg.com/boards/display_thread.php?id=131086
Adderd's last dev posting: http://www.verge-rpg.com/boards/display_thread.php?id=130022
--------------------------
Overkill
busy. But in a way that isn't quite murdering me yet. One more final
to go (MY FINAL FINAL LAFF) and then I'll be at home.
I made a lengthy post to this thread like a week ago, but for some
reason it didn't actually show up. On top of that, I forgot to make a
backup before submitting it. So yeah. Er, I'll try my best to
summarize what I said before, with hopefully as much clarity as
previously.
I certainly agree that the current source could use a lot more
documentation and explanation. I usually made sure to comment my code
modifications to be understandable. I can't really remember though. It
was a while back. If I didn't document my stuff well, shame on me!
The lack of direction is probably rooted in the lack of overall
interest in Verge. I think we need to respark the interest within the
community again. Make more posts on the forums, more pretty picture
galleries, more news, more demo alarms, post the goshdarned compo
results already, more public build releases. Why are we holding back a
year or two's worth of changes to the source from the community? If
there are problems with the builds, we probably have no idea what they
are by this point anyways. I'm sure if they notice the devs love them
again, they'll return the love by making things. Then we get
suggestions on what to do, and discover bugs to patch that may have
slipped through the dev testing. Just compile up a release for Windows
and the Mac and unleash it on the community. We can probably let the
Linux users dig into the SVN repo.
In response to Grue's latest enumerated list:
1. Make it work on Mono or something? I dunno. Wasn't Ioachim doing
something with that? Also, yell at tat!
1a. There are some things that are a little difficult to interface
with VergeC at the moment. All internal CHR/VSP/whatever image data is
sort of stored poorly so it's a pain to get it to work at the moment.
Look at this fun code to blit the image. Why aren't frames all
separate image pointers instead of staying in memory as a large image
that has to be casted into smaller ones repeatedly?
container->data = (void *) ((int) rawdata->data +
(frame*fxsize*fysize*vid_bytesperpixel));
TBlit(x, y, container, dest);
Hm, actually. Wait. I guess if the big image is assigned a handle,
we've got access to the raw image? Hmmm.
A lot of other stuff is just annoying arrays that need to be converted
into std::vector stuff so that things can be added and removed easily
and without upper limits that are set once on initialization.
When I get back home in a few days, I'll relook the code situation!
I've not been messing with Verge's codebase in some time, so some of
it's a little alien at the moment.
2. I think I answered most of it.
3. Hm, we *could* have some sort of simple command-line conversion
tool that turns an existing file format with editors on those
platforms into .chr/.vsp/.map whatever.
4. I don't quite remember how I set up Verge to compile in Visual C++
2005 Express or Visual Studio now. But I do remember most of the
useful information for altering the codebase. So if someone else does
a "HOW TO COMPILE THIS LAWD" I can follow with a "HOW TO MODIFY VERGE
AND MAKE YOUR DREAMS COME TRUE".
5. I plan on reassessing when I get more time and in the right mood.
6. Agreed.
> IkimashoZ and GuruOfReason's postinghttp://www.verge-rpg.com/boards/display_thread.php?id=131086
AdderD
On Apr 9, 8:06 pm, ben.mcg...@gmail.com wrote:
>
> Now, the one outstanding issue with MapEd3, in my mind, is not that
> it's buggy or lacking in interface, but really that it's one-platform,
> whereas v3 now has multiple platforms for use. And ever since the mac
> version of v3 was made, would-be mac game-creators have had absolutely
> no venue for editing. Ditto for Linux users of the very, very silent
> branch adderd was preparing (and one can noly assume he got frustrated/
> bored due to lack of response and organization (adderd, if you're out
> there, please chime in?)) and the tenative new branch of the linux
> port mentioned by IkimashoZ and GuruOfReason' recently.
Ok, I replied in the thread from GuruOfReason. I did kind of just drop
the ball on the linux port. But what I really want is to unify the
code bases. It's insane for a small time project like verge to try to
keep up three seperate interfaces. I think that it would be worthwhile
switching to QT for the GUI parts and using SDL for graphics and just
overall using cross platform libraries. In fact, I'm toying with the
idea of doing just that -- A total fork that would be cross platform
for all the currently supported platforms (well, maybe not GP2X...) I
know people probably hate that idea though... ;-(
Glenshope
its a problem of speed on older machines we can simply go back and re-
edit the code to use floating point like I have had to do up till now,
but it is much nicer if while working on the base code I don't have to
worry about such things. Also I would like to point out that Maped
really could use more support for the Layer system. Early on and even
now I find myself running into problems such as not knowing which
layer different tiles are on, maybe some small number in the corner of
each tile to show the layer the top tile is, or at least an option for
such. Also in order to have an animation built into the map you need
to set the tiles right next to each other when you have them. It is
use tiles x-y. It would be nice to have some support for use tiles x,
z, d... Or you could even do, use tiles x-y skipping 2 tiles between
each. That way when I upload a piece of beach front that is 64x64, I
don't have to go back and cut it up to a ton more pieces, since I have
it animated.
Now as to implementing this myself I have no idea where to start.
Sorry about the other post I have removed it since I originally meant
to speak in this conversation anyway.
add...@kkmfg.com
> I don't think there's any need for a fork to do that! As long as
> you're not removing features, I don't think anyone would mind if you change
> the underlying libraries. It would be easy to get the Windows version to
> run using SDL and not DirectX. I've never used QT (how well does it play
> with SDL?) but if you want to move to it, I think you'd have support or at
> least neutrality - we don't have much GUI anyway. My only problem with
> this kind of a plan is the work that goes into it that isn't going
> elsewhere.
Well, fork was a bad word to use I guess. In a way it's what I'd be doing
but not really. It would be best to kind of cut the cord with the main
project while it is being done but the end goal is to eventually
transition the main branch to the unified code base. SDL is probably a
little slower than just using DirectX but in both linux and windows SDL
can use acceleration. I really do want to transition to using SDL as much
as possible because it creates a code base which is very portable. The
joystick, mouse, video, keyboard, and even sound can all use SDL on
Windows, OSX, and LINUX. It should even make a windows mobile version
possible. I don't know what would happen for GP2X or PSP though.
>
> (Having a QT GUI would also open the door to having a special
> interface for a in-engine map editor.)
>
Yeah, it would allow for some extra goodies in the future. At least when
such goodies are added they'd simultaneously appear on all OS's.
Ben McGraw
-gru
andy
the authoritative source tree for all platforms. Switching the
Windows build to use SDL is a great first step. (I've done a few (:D)
SDL ports of the old DOS Verges, and they were all plenty fast)
Factoring out the platform-specific code for platforms on which SDL
cannot run is the second.
Grue said something interesting: "I care far more about the PC/Linux/
Mac versions than anything else." This kind of prioritization is a
really useful tool, but only when everyone has the same set of
priorities. A useful exercise would be for the group to agree on a
stack-ranked set of priorities. This allows you to say things like
"well, this gizmo would be cool, but it would make it much harder to
run on Linux and OSX, and we've decided that that's our top priority
right now, so we have to pass up on this gizmo."
-- andy
> --
> -uəq
> --http://www.breadbros.comhttp://www.verge-rpg.com
kattkieru
I highly doubt any of you know me. I used to play with Verge a lot
back when v1 was released, and later with V2 and Zeux World. (Think I
still need to clock that one.)
I wanted to chime in on the V3 stuff. First, here's a Mac PPC build
out of the current SVN tree (as of 10 May 2007):
http://ministryofdoom.org/cloud/verge/verge3-rev30.dmg
Whomever made the XCode project is a brilliant example of a human
being. Building on Mac PPC is exceedingly simple:
1) In the terminal, make a directory for the files.
2) Go into the directory, then type the command to copy the SVN tree:
svn co http://www.verge-rpg.com/svn/verge3/
(It'll try logging in once with your system user name; once that fails
log in with anonymous/anonymous. I don't know SVN so I don't know how
to override that.)
3) Once all that's downloaded, open the verge3/mac/verge3.xcodeproj
file in XCode.
4) In XCode, uncheck the "libfmodx86.a" file in the fmod folder.
5) Hit build, grab a tea.
When all's done the app resides in verge3/mac/build/Development.
I don't know what building a universal binary would entail, but I
assume that having both versions of the fmod lib in the distribution
means someone's tried already. I don't have an X86 Mac so I haven't
done any UB testing yet, at all.
Also, I can't test the binary because every game package I download
seems to be for an older version of Verge, and the V3 binary won't run
them.
Lemme chime in on a few other issues:
- The OSS community will, I think, shy away from Verge until fmod is
replaced with something fully OSS and not just free "until you decide
to sell your product." In a similar vein, getting Verge3 compiling
with mingw or cygwin would also be a good step toward garnering OSS
community support.
- The Mac community will shy away from Verge until two things happen:
1) The editors go Mac-native.
2) The graphics improve.
I know that the latter is a stereotype of Mac users in general, but
sometimes stereotypes are stereotypes for a reason. The number one
complaint of software getting ported from other systems to the Mac is,
"Eww, it looks so horrible and un-mac-like." There needs to be a demo
with better graphics than Sully.
- It would be nice for Verge3/Mac to be able to have all its resources
recognized inside the app bundle. IE, on startup it looks in the app
bundle's Contents/Resources directory first, then looks in the parent
folder of the app bundle for data. (It'd be another step towards
garnering Mac user support.) Not that I know whether this feature is
already implemented; I'm just starting to look at the code.
- SDL and QT do work together, but IIRC you have to do something weird
like YUVOverlay = SDL_CreateYUVOverlay(352, 288, SDL_YV12_OVERLAY ,
screen); Don't quote me on that; I hardly know anything about SDL at
all. I haven't even done graphics programming in three-ish years.
- A lot of the serious developers out there will not come on board
until makefiles / sconsfiles / jamfiles are provided, I think. While
I appreciate the work that went into the XCode project, I hate XCode,
and I've met a number people over the years who also hate IDEs.
Funnily enough, though, the majority of the Mac community would
probably shy away from software without the XCode project file. No,
you can't win.
On Maped3:
- I figure you need to make a choice: use the Verge3 engine as the map
editor, or put resources into a new map editor that's cross-platform
and shares bits of the Verge3 code (level loading/saving, etc.). Qt
or wxWidgets would work, but you want to double-check the licensing
restrictions. (I forget: does the BSD license mesh with the GPL if
you mix the code?) If you don't use a windowing library, you'd have
to write a whole slew of new GUI controls within Verge.
- Mono why?
I can't make any promises or anything as to how involved I want to be
with Verge3/Mac, but doing builds isn't a huge time sink. Can someone
direct me to a working link for v3 demo files?
One last thing: the main page doesn't invite developers at all. The
first thing I tried was to download verge3/mac or sully/mac. Both the
Windows and Mac links are broken and lead me to a Bad Monkey page.
Then I looked at the top for a "development" link, and couldn't find
one. Eventually I checked the About page and found the SVN
information there? Huh?
Anyway, looking forward to watching this conversation go forwards.
~ Charles
Charles Wardlaw
> What happens if you don't do this? Even if you're running a PPC Mac,
> you should still be able to build the x86 version of the code,
> shouldn't you? What version of Xcode are you using?
v2.4. If I don't delete that library, it warns about the lib being
for the wrong architecture and then links happily. That scared me.
It seemed to build the PPC only version by default from the XCode
project file that's in SVN. I know I *can* build the X86 code, but I
only know how to do so from the command line. Like I said in the last
mail I touch XCode reluctantly and with a long stick. ^_^;
> I should also say, for the record, that it's not *quite* that easy to
> build - you're lucky to have SDL installed in the right place.
Oh. Right. Well, SDL itself builds quite easily. Perhaps, since
libz and corona are already in the source tree, SDL could be added to
SVN and to the build process? Or is it too large and are there too
many pieces? It's just a thought; me personally, I like the build
as-is.
> I'm also looking for testcases! The current SVN of Sully is a
> candidate you might try, but I don't know how many of the recent
> additions would be tested by it.
Dumb question but where is that?
> I agree with the first point, although I guess it depends on what you
> mean by "native". Doing a full editor with, say, Cocoa would be a
> major undertaking with a small amount of benefit compared to making
> one with QT/wxwidgets that would run on other platforms, too.
I don't mean Cocoa, not at all. Both Qt and wxWidgets handle the
native widget look just fine. The "native" to which I was referring
is, essentially, eye candy, icon and widget spacing (following the
Apple HIG), native file save and load dialogues (which both toolkits
handle seamlessly), etc. Shiny toolbar icons. Things that would look
good on windows, linux, or Mac. The thing is not to waste too much
screen real estate and to strive for no non-blocking windows and
alerts. Most importantly: no wizards.
> As for the graphics, I'm not sure. I feel like Verge is pretty
> explicitly "old-skool" and fancy graphics aren't the point. That
> being said, I don't think anyone would object to pretty new demos.
Especially if the demo showed easier ways to get larger, tiled
graphics into the game apart from splitting them into tiny tiles.
(There was talk earlier in this thread on 2x tile distances, etc.) I
dunno. There's a difference between "old-skool" and "16-color." Even
then, look at Commander Keen. All they had were 16 colors, but they
did a lot with them.
I don't mean to insult the Sully graphics artist either -- they're
aiming for something, and they achieve it. But look at FreeCiv. They
started off with standard OSS graphics and now they ship with tile
sets that look downright professional.
> This I did. The reason it's not like this out-of-the-box is for
> parity with the PC build - you put verge in a folder with a system.vc
> and some resources and open it - POW, you've got a game. The other
> strategy is good for releasing a game when you're done, but it's
> annoying to have to delve into the package while developing. It's
> controlled by USE_VERGE_RES_DIR in SDLMain.m, which causes verge to
> search in Resources/verge instead of the parent dir.
Oh nice. Can that be moved out into the Info.plist in the app bundle?
Most end users aren't going to want to / be able to recompile.
> On the other hand, if that's a real barrier, Verge isn't especially
> hard to build. A makefile wouldn't be too hard - I assume adderd made
> one for the linux build already anyway?
Yeah, that was something I wanted to check next. I don't think
there's a makefile in SVN, so I was going to try pulling apart the
XCode project and see if I can build on Linux.
> I think this is probably one of the biggest problems. This mailing
> list is a good first step in the right direction. I say we get some
> demo code, test the mac build, get ovk to produce some windows
> binaries and release! That would be another good step.
Also, the CSS seems to be targeted at IE.
~ Charles
ben.m...@gmail.com
short list of "goddamnit, add already."
fixed point math became unfashionable in about 1Q 1998, IIRC.
ben.m...@gmail.com
of code?
Ben McGraw
The sully svn is not yet public. I expect it to be within the day.
I once again stress my desire for the capabilities for an in-engine mapeditor so the mac and 'nix folk can edit. Andy's points on the subject are good, but I've seen no movement on the "external, platform agnostic" front at all. I mean, is anyone willing to pick up the desperately needed "hay, we needs a Resource Editor for everyone kthx" torch? Bueller?
To Jesse and/or kattkieru:
Could you outline what's necessary to make a build on a mac?
To adderd and/or Mr. Torvalds:
Could you outline what's necessary to make a build on a mac?
To everyone:
What's needed to converge the three builds to one ubiquitous head? What are valid open-source options to replace fmod with, for one?
Yes, the css on vrpg.com is very bad. There's a gorgeous site redesign in the kitty, but I've been running on severe free time deficit for over a year now, so... yeah. I'll make you kids a deal: we get the three operating systems meshed up and some sort of map and sprite editor working across the board, and I'll pick up that torch again. Any takers?
add...@kkmfg.com
> Am I missing Jesse's response to this? I see it not.
I didn't see it either. I'm betting it was actually a private email and
that the poster of the email we saw just replied to the list.
> I once again stress my desire for the capabilities for an in-engine
> mapeditor so the mac and 'nix folk can edit. Andy's points on the subject
> are good, but I've seen no movement on the "external, platform agnostic"
> front at all. I mean, is anyone willing to pick up the desperately
> needed "hay, we needs a Resource Editor for everyone kthx" torch?
> Bueller?
Not me right now. I'd like to get the three main branches merged together
but after that who knows...
> To adderd and/or Mr. Torvalds:
> Could you outline what's necessary to make a build on a mac?
I assume you meant to end that with linux so...
On the linux version I did there was a makefile (a VERY simple one!). But
you had to manually build all of the dependencies and put them somewhere
in the include/lib paths. Generally /usr/include and /usr/lib I believe.
It wasn't a really great system and at least one person was not able to
get it to compile, probably because of some dependency issues.
Ideally a configure script would be created or automake used or something
of that sort that allows the source to be configured a bit.
I believe that OSX has GCC as well and it's BSD based so it's *possible*
that something could be cooked up that would compile on either linux or
OSX without any source modifications. Just run ./configure and make all
and you are done on either platform. Not sure that most mac people would
want to pass up using XCode though.
>
>
> To everyone:
> What's needed to converge the three builds to one ubiquitous head? What
> are valid open-source options to replace fmod with, for one?
There is SDL-Sound which plays MP3, MOD, MIDI, WAV, etc. It has built in
MP3 and MIDI support but needs extra libraries to play anything else
(vorbis, MOD, S3M, 669, etc). SDL-Sound is a *royal* pain in the ass to
get compiled. On windows I ended up using three different C++ compilers to
get it and all it's dependencies compiled (I think mikmod would only
compile under VC6 and some of the libraries had only VC2003 projects and I
didnt want to convert them, and sdl-sound itself I compiled with VC2005).
That all might not be so bad if we just precompile that junk (at least for
windows) and include it with the verge source. The point isn't to have to
compile 700 external dependencies anyway.
I have gotten sdl-sound all compiled and theoretically working so I could
just put that stuff in the source branch but I haven't yet tried compiling
it under linux to see what happens. Strangely I usually have better luck
getting external stuff to compile in linux than I do in Windows. Maybe
it's because configure scripts are a gift from heaven. ;-)
> --
> -uəq
> --
> http://www.breadbros.com
> http://www.verge-rpg.com
>
>
> >
>
>
Ben McGraw
On Fri, May 11, 2007 11:36 am, Ben McGraw wrote:
> Am I missing Jesse's response to this? I see it not.
I didn't see it either. I'm betting it was actually a private email and
that the poster of the email we saw just replied to the list.
Naughty!
> I once again stress my desire for the capabilities for an in-engine
> mapeditor so the mac and 'nix folk can edit. Andy's points on the subject
> are good, but I've seen no movement on the "external, platform agnostic"
> front at all. I mean, is anyone willing to pick up the desperately
> needed "hay, we needs a Resource Editor for everyone kthx" torch?
> Bueller?
Not me right now. I'd like to get the three main branches merged together
but after that who knows...
> To adderd and/or Mr. Torvalds:
> Could you outline what's necessary to make a build on a mac?
I assume you meant to end that with linux so...
I did. I've been awake since yesterday.
On the linux version I did there was a makefile (a VERY simple one!). But
you had to manually build all of the dependencies and put them somewhere
in the include/lib paths. Generally /usr/include and /usr/lib I believe.
It wasn't a really great system and at least one person was not able to
get it to compile, probably because of some dependency issues.
Ideally a configure script would be created or automake used or something
of that sort that allows the source to be configured a bit.
Who would this mythical white knight be?
I believe that OSX has GCC as well and it's BSD based so it's *possible*
that something could be cooked up that would compile on either linux or
OSX without any source modifications. Just run ./configure and make all
and you are done on either platform. Not sure that most mac people would
want to pass up using XCode though.
what is the magic of configure? what is this "xcode" of which you speak? I am but a simple caveman...
>
>
> To everyone:
> What's needed to converge the three builds to one ubiquitous head? What
> are valid open-source options to replace fmod with, for one?
There is SDL-Sound which plays MP3, MOD, MIDI, WAV, etc. It has built in
MP3 and MIDI support but needs extra libraries to play anything else
(vorbis, MOD, S3M, 669, etc). SDL-Sound is a *royal* pain in the ass to
get compiled. On windows I ended up using three different C++ compilers to
get it and all it's dependencies compiled (I think mikmod would only
compile under VC6 and some of the libraries had only VC2003 projects and I
didnt want to convert them, and sdl-sound itself I compiled with VC2005).
That all might not be so bad if we just precompile that junk (at least for
windows) and include it with the verge source. The point isn't to have to
compile 700 external dependencies anyway.
I have gotten sdl-sound all compiled and theoretically working so I could
just put that stuff in the source branch but I haven't yet tried compiling
it under linux to see what happens. Strangely I usually have better luck
getting external stuff to compile in linux than I do in Windows. Maybe
it's because configure scripts are a gift from heaven. ;-)
add...@kkmfg.com
>
>> you had to manually build all of the dependencies and put them
>> somewhere in the include/lib paths. Generally /usr/include and /usr/lib
>> I believe.
>> It wasn't a really great system and at least one person was not able to
>> get it to compile, probably because of some dependency issues.
>>
>> Ideally a configure script would be created or automake used or
>> something of that sort that allows the source to be configured a bit.
>
>
> Who would this mythical white knight be?
Well the general gist of it is that there are a few different programs in
linux (and I'd figure OSX) which serve as a way to configure the compiling
of a certain application. Such needed configuration includes: Changing
where to look for header files and libraries, and picking which features
to enable. With configure scripts verge could support both sdl-sound and
fmod and you would just need to tell configure which one you want. It will
in turn set a define for that feature. For instance, running configure
might look something like:
./configure --enable-sdl-sound --include /usr/include/sdl
Which would select using sdl-sound and add /usr/include/sdl to the search
path for header files.
This is all very nice because configure will then write the makefile for
you and take care of all of the nitty gritty stuff. It makes the whole
process a lot more likely to succeed.
In the verge code you would then conditionally compile things based on the
defines.
>
> what is the magic of configure? what is this "xcode" of which you speak?
> I
> am but a simple caveman...
>
XCode is the GUI based development platform for OSX. I've never used it
but I believe it supports C, C++, and ObjectiveC.
> I might have someone with a large amount of experience with SDL-Sound who
> could do this. A more pressing question to me is "is SDL Sound the
> right choice?"
>
Is it the right choice? I don't know. But if we use SDL then it might be.
It's made for tight integration with SDL and it's cross platform so it's a
potential solution at any rate.
Jesse Rusak
the original reply, for reference.
--
Hi There,
Just thought I'd respond to some of your points, while trying not to
blush from the compliments.
> 4) In XCode, uncheck the "libfmodx86.a" file in the fmod folder.
What happens if you don't do this? Even if you're running a PPC Mac,
you should still be able to build the x86 version of the code,
shouldn't you? What version of Xcode are you using?
I should also say, for the record, that it's not *quite* that easy to
build - you're lucky to have SDL installed in the right place.
> I don't know what building a universal binary would entail, but I
> assume that having both versions of the fmod lib in the distribution
> means someone's tried already. I don't have an X86 Mac so I haven't
> done any UB testing yet, at all.
The UB version works just as well - I made one just the other week.
> Also, I can't test the binary because every game package I download
> seems to be for an older version of Verge, and the V3 binary won't run
> them.
I'm also looking for testcases! The current SVN of Sully is a
candidate you might try, but I don't know how many of the recent
additions would be tested by it.
> Lemme chime in on a few other issues:
>
> - The OSS community will, I think, shy away from Verge until fmod is
> replaced with something fully OSS and not just free "until you decide
> to sell your product." In a similar vein, getting Verge3 compiling
> with mingw or cygwin would also be a good step toward garnering OSS
> community support.
This has come up before, if I recall correctly. Did you find a way
around this, Grue?
> - The Mac community will shy away from Verge until two things happen:
> 1) The editors go Mac-native.
> 2) The graphics improve.
> I know that the latter is a stereotype of Mac users in general, but
> sometimes stereotypes are stereotypes for a reason. The number one
> complaint of software getting ported from other systems to the Mac is,
> "Eww, it looks so horrible and un-mac-like." There needs to be a demo
> with better graphics than Sully.
I agree with the first point, although I guess it depends on what you
mean by "native". Doing a full editor with, say, Cocoa would be a
major undertaking with a small amount of benefit compared to making
one with QT/wxwidgets that would run on other platforms, too.
As for the graphics, I'm not sure. I feel like Verge is pretty
explicitly "old-skool" and fancy graphics aren't the point. That
being said, I don't think anyone would object to pretty new demos.
> - It would be nice for Verge3/Mac to be able to have all its resources
> recognized inside the app bundle. <snip>
This I did. The reason it's not like this out-of-the-box is for
parity with the PC build - you put verge in a folder with a system.vc
and some resources and open it - POW, you've got a game. The other
strategy is good for releasing a game when you're done, but it's
annoying to have to delve into the package while developing. It's
controlled by USE_VERGE_RES_DIR in SDLMain.m, which causes verge to
search in Resources/verge instead of the parent dir.
> - SDL and QT do work together, but IIRC you have to do something weird
> like YUVOverlay = SDL_CreateYUVOverlay(352, 288, SDL_YV12_OVERLAY ,
> screen); Don't quote me on that; I hardly know anything about SDL at
> all. I haven't even done graphics programming in three-ish years.
Well, that sounds good!
> - A lot of the serious developers out there will not come on board
> until makefiles / sconsfiles / jamfiles are provided, I think. <snip>
Really? Weird. I mean, you can still build it on the command line if
you want. I usually use TextMate + XCode for verge development, and
you could just drop XCode and use xcodebuild right from TextMate (or
whatever) if you like.
On the other hand, if that's a real barrier, Verge isn't especially
hard to build. A makefile wouldn't be too hard - I assume adderd made
one for the linux build already anyway?
> On Maped3:
>
> - I figure you need to make a choice: use the Verge3 engine as the map
> editor, or put resources into a new map editor that's cross-platform
> and shares bits of the Verge3 code (level loading/saving, etc.). Qt
> or wxWidgets would work, but you want to double-check the licensing
> restrictions. (I forget: does the BSD license mesh with the GPL if
> you mix the code?) If you don't use a windowing library, you'd have
> to write a whole slew of new GUI controls within Verge.
Agreed. I think either of these is a lot of work, but viable. My only
comment is that many GUI controls do already exist (in semi-stealable
form) in verge apps.
> One last thing: the main page doesn't invite developers at all. The
> first thing I tried was to download verge3/mac or sully/mac. Both the
> Windows and Mac links are broken and lead me to a Bad Monkey page.
> Then I looked at the top for a "development" link, and couldn't find
> one. Eventually I checked the About page and found the SVN
> information there? Huh?
I think this is probably one of the biggest problems. This mailing
list is a good first step in the right direction. I say we get some
demo code, test the mac build, get ovk to produce some windows
binaries and release! That would be another good step.
> Anyway, looking forward to watching this conversation go forwards.
Me, too.
- Jesse
andy
A general rule you can apply to basically all code is that
"duplication is bad." Duplicated logic always implies duplicated
work.
-- andy
kattkieru
I hope this post doesn't come through twice; Google Groups seemed to
eat it the first time even though it said it posted. If it I
apologize, although I've since played around a bit and wanted to
change what I said anyway.
As far as the Mac build goes, as I detailed in my previous mail the
steps were quite easy. Jesse did point out that it was easier for me
because I already had SDL installed. I would like to say that SDL is
not a pain to build and install, but that's only true if you're only
building for one architecture. Their desire to maintain binary
compatibility on the PPC side with OS X 10.2 means building the
universal framework requires a bit more jumping through hoops.
I think the easiest thing is going to be adding SDL.framework to SVN
and having it be a part of the /verge3/mac/ folder or to tell users
that they have to download the prebuilt SDL framework (http://
www.libsdl.org/cgi/docwiki.cgi/ -- "Runtime Library") and add it to
the XCode project.
I had trouble with building a UB when it came to fmod and SDL. With
SDL I just downloaded the prebuilt framework; with fmod I ended up
building a universal library:
lipo -arch i386 libfmodx86.a -arc ppc libfmod.a -create libfmodub.a
I added that and removed the other two and I stopped getting
warnings. Seems the way to go. Then again, XCode's also started
giving me a different warning about libs not matching architectures
and being skipped (where before it was warning about not matching, but
still including, near as I could tell.)
Once I get more situated in XCode (need to google for a decent, no-
nonsense primer) I can sit down and write up some Mac build help.
Wish I had a virgin system to do tests on.
On automake: most of the software I play with on my Mac that's not
commercial comes with the configure/make/sudo make install dance,
although I also install a lot through Fink (http://
www.finkproject.org/) which is a port of apt-get for Darwin. I
generally use Fink to install the missing parts of the GNU toolchain
(and an updated fileutils, as the version that ships with Mac OS X
doesn't have colorization) and build other stuff by hand. Anyone
who's going to be building Verge3 from source will likely already have
Fink installed, and if not it can be suggested as the best course of
action.
On integrated maped:
It cuts down on the need for yet another external library, shares code
with Verge3 (maybe libverge3.a could be created if people want a
separate program), and the stuff that gets written and added to this
MapEd would probably benefit VC coders in the long run with new UI
stuff and new ways to modify maps through VC. Sounds a lot better to
me than using Qt or wxWidgets to write something totally new. What
would the actual benefits of writing an all-new, multiplatform map
editor using a windowing toolkit be?
New build uploaded; now a universal binary with SDL.framework inside
the app bundle. If people with Intel macs and folks who don't have
SDL already installed could test it that'd be great.
http://ministryofdoom.org/cloud/verge/verge3-rev30-ub.dmg
~ Charles
kattkieru
project doesn't build without some work on my laptop, and the static
library was including the wrong CD Rom module so builds would quit
with missing symbols.
I eventually got it built, though. I was thinking that a static
library and the required headers might be better than the framework
because there's no copying into the app bundle. Here's a file:
http://ministryofdoom.org/cloud/verge/sdl-changes.tgz
In it are two folders. If you back up the in-SVN mac/verge3.xcodeproj
file and then uncompress it in the verge3/ folder it'll write a new
version of the XCode project and a new SDL folder. I removed the
SDL.framework dependency and replaced it with the static lib.
It all builds fine now, and as generating the actual static UB lib
took a bit of work I'd recommend this as the actual thing to put in
SVN for Mac. If Jesse or someone else could check this that'd be
great. I'm still new to this and I worry that what I'm doing might
make someone else's machine explode.
^_^;
~ Charles
Jesse Rusak
> and having it be a part of the /verge3/mac/ folder or to tell users
> that they have to download the prebuilt SDL framework (http://
> www.libsdl.org/cgi/docwiki.cgi/ -- "Runtime Library") and add it to
> the XCode project.
>
I think that makes good sense. I'd side towards the former that way
there are no dependancies for game-players. I don't know why I didn't
set up the project to package SDL in the App, but I think it makes
good sense to stick it in there automatically.
> I had trouble with building a UB when it came to fmod and SDL. With
> SDL I just downloaded the prebuilt framework; with fmod I ended up
> building a universal library:
>
> lipo -arch i386 libfmodx86.a -arc ppc libfmod.a -create libfmodub.a
>
<snip> Good idea! We should definitely stick that in SVN with the
updated project file. Either send it to me or talk to Grue about
getting a commit bit.
> Once I get more situated in XCode (need to google for a decent, no-
> nonsense primer) I can sit down and write up some Mac build help.
>
Awesome.
I agree that Fink is awesome, but I don't see why it's better than
just downloading the .app. Especially because verge games typically
come with the .app in the folder. (At least, on Windows)
> New build uploaded; now a universal binary with SDL.framework inside
> the app bundle. If people with Intel macs and folks who don't have
> SDL already installed could test it that'd be great.
>
This seems to work fine on a couple recent games I've got hanging
around on my Intel mac.
Jesse Rusak
have a sec.
- Jesse
kattkieru
> updated project file. Either send it to me or talk to Grue about
> getting a commit bit.
http://ministryofdoom.org/cloud/verge/libfmodub.tgz
I'll wait on commit until I know the codebase more (which is to say, I
haven't looked inside any of the verge3 source files yet). If
anyone's been working on that codebase primer now's the time to
debut. ;)
> I agree that Fink is awesome, but I don't see why it's better than
> just downloading the .app. Especially because verge games typically
> come with the .app in the folder. (At least, on Windows)
Oh sorry... I meant that Fink could be suggested as the best way to
install dependencies. Naturally downloading the app by itself and
just dragging it into /Applications/ would be the way for me to go
too.
> This seems to work fine on a couple recent games I've got hanging
> around on my Intel mac.
That's good to hear. Are they games available at Verge-rpg.com? I
still need a test case or three. @Grue: I'm the single person who
doesn't have access to the Sully SVN. I'm asking you to do it. ;)
~ Charles
Ben McGraw
> <snip> Good idea! We should definitely stick that in SVN with the
> updated project file. Either send it to me or talk to Grue about
> getting a commit bit.
http://ministryofdoom.org/cloud/verge/libfmodub.tgz
I'll wait on commit until I know the codebase more (which is to say, I
haven't looked inside any of the verge3 source files yet). If
anyone's been working on that codebase primer now's the time to
debut. ;)
Yeah, someone, anyone, please write a doc. :(
> I agree that Fink is awesome, but I don't see why it's better than
> just downloading the .app. Especially because verge games typically
> come with the .app in the folder. (At least, on Windows)
Oh sorry... I meant that Fink could be suggested as the best way to
install dependencies. Naturally downloading the app by itself and
just dragging it into /Applications/ would be the way for me to go
too.
...Fink?
> This seems to work fine on a couple recent games I've got hanging
> around on my Intel mac.
That's good to hear. Are they games available at Verge-rpg.com? I
still need a test case or three. @Grue: I'm the single person who
doesn't have access to the Sully SVN. I'm asking you to do it. ;)
~ Charles
Email me and I'll set up read/write on the engine project for you, kattkieru.
Jesse Rusak
of using the .framework? Was it just that building the framework was
a pain? Otherwise, I think the framework is more "the right way" to go.
Also, as for games, I think the best place to look is the last 2
compos. They're small, but recent; I think I've run most of them,
possibly with minor tweaks like removing a min function or something
from the system.vc; check out the links from these 2 items:
http://verge-rpg.com/boards/display_thread.php?id=129882 (I know I've
run all of these)
http://verge-rpg.com/boards/display_thread.php?id=130995 (I know I've
run at least overkill's)
I'll test your new UB libfmod and check it in if everything seems
hunky-dory.
- Jesse
On 13-May-07, at 6:30 PM, kattkieru wrote:
kattkieru
> of using the .framework? Was it just that building the framework was
> a pain? Otherwise, I think the framework is more "the right way" to go.
Maybe. For me, though, if we're just going to end up copying the
framework into the app bundle then it's totally lost its usefulness.
The whole point of them is that they're dylib wrappers, but if every
program has a copy inside you might as well be statically linking.
Also, when you use the framework it includes all the header files that
are inside of it, which are just extra files that don't need to be
there. I dunno. I just figure, if you want self-contained apps then
static libs are the way to go. I do tend to be extremely old-
fashioned, though. Both options are open now, so it's up to you to
pick the one you're most comfortable with.
> Also, as for games, I think the best place to look is the last 2
> compos. They're small, but recent; I think I've run most of them,
> possibly with minor tweaks like removing a min function or something
> from the system.vc; check out the links from these 2 items:
>
> http://verge-rpg.com/boards/display_thread.php?id=129882(I know I've
> run all of these)http://verge-rpg.com/boards/display_thread.php?id=130995(I know I've
> run at least overkill's)
Cheers, I'll have a look. Right now I'm in the middle of building Qt
4.3 RC1. It took roughly all weekend to make that work and it
compiled in debug mode because it's not a final, so it's about six gig
of HD space I'm waiting to reclaim. ^-^ But I had some ideas I wanted
to test out.
~ C
kattkieru
Yeah, I dunno why they called it that, either. mac-apt-get would have
been better.
For right now, though, I don't think it'll be necessary for developers
to use it to compile the Mac version of V3. Most of the serious
dependencies go into SDL anyway.
> www.verge-rpg.com/svn/sully is now publically readable.
Rock on. I grabbed it today. Some of it works in my V3 Mac build by
just putting the app into the directory. ^-^ It's missing verge.cfg,
so it doesn't load as-is in SVN. There are also a number of save
games in SVN that might not need to be there?
> Email me and I'll set up read/write on the engine project for you,
> kattkieru.
I'll drop you a mail after this. I suppose I should also learn how to
use SVN, huh. Will that include write access to Sully?
By the by, the new Sully demo is *amazing* compared to the V2
version. Overworld map FTW! There're a lot of spots that throw up
errors (like the big red circle on the overworld -- click it and it
say something about no multiple windows yet and then crashes). But
the blending and the SNES-style transitions? Awesome.
The other thing that the demo brings up is the lack of true full-
screen in the mac version... There a simple way to get the screen to
stretch fully? Changing xres and yres in verge.cfg just shifts the
screen around. There're some other things too, like the big compile
at the beginning and the fact that, at least in the mac version,
tabbing out doesn't work and the intro compile can't be canceled,
like, at all. Might be even nicer if the screen changed a bit to show
the current file being compiled / loaded or something. Also: is there
a way to make the compiled files save out so that you don't have to
sit through the process again?
~ Charles
Jesse Rusak
> screen in the mac version... There a simple way to get the screen to
> stretch fully? Changing xres and yres in verge.cfg just shifts the
> screen around.
Try setting "windowmode 0" in verge.cfg. Sully may also override the
xres/yres setting?
> There're some other things too, like the big compile
> at the beginning and the fact that, at least in the mac version,
> tabbing out doesn't work and the intro compile can't be canceled,
> like, at all. Might be even nicer if the screen changed a bit to show
> the current file being compiled / loaded or something.
I agree. We'd have to spawn a separate UI thread, or else throw a
bunch of SDL_PollEvent (or whatever it's called) into the compilation
steps.
> Also: is there
> a way to make the compiled files save out so that you don't have to
> sit through the process again?
They're always saved out - if you set "releasemode 1" in verge.cfg,
it will look for system.xvc instead and use that, skipping the
compile. Note that, unfortunately, the PPC and x86 .xvc files are
different endian.
Jesse Rusak
>> of using the .framework? Was it just that building the framework was
>> a pain? Otherwise, I think the framework is more "the right way"
>> to go.
>
> Maybe. For me, though, if we're just going to end up copying the
> framework into the app bundle then it's totally lost its usefulness.
> The whole point of them is that they're dylib wrappers, but if every
> program has a copy inside you might as well be statically linking.
I think we can copy it into "Shared Frameworks" (or maybe just
"Frameworks"?) which lets the app use it, unless a newer version is
installed on the system, in which case it uses that. This might be
the best of both worlds?
> Cheers, I'll have a look. Right now I'm in the middle of building Qt
> 4.3 RC1. It took roughly all weekend to make that work and it
> compiled in debug mode because it's not a final, so it's about six gig
> of HD space I'm waiting to reclaim. ^-^ But I had some ideas I wanted
> to test out.
Sounds interesting! Let us know how it goes. I've posted your
libfmodub to SVN, btw.
kattkieru
> "Frameworks"?) which lets the app use it, unless a newer version is
> installed on the system, in which case it uses that. This might be
> the best of both worlds?
It would be during the development phase, sure. But when it comes to
distributing games with custom apps, one of Verge's strong points has
always been the
1) Unzip.
2) Play
style of distribution. With a shared framework there'd need to be an
installer or something. I guess the argument could go either way --
mac users would run the "Install Verge Shared Libraries" package once
and then never worry about it again.
Up to you.
~ C
kattkieru
> xres/yres setting?
Haven't looked into the Sully code too much yet, so I don't know...
But the windowmode thing didn't work for me? I tried a bunch of
settings from one of the manual pages.
> They're always saved out - if you set "releasemode 1" in verge.cfg,
> it will look for system.xvc instead and use that, skipping the
> compile. Note that, unfortunately, the PPC and x86 .xvc files are
> different endian.
Ahh... I'll play with that more, then.
Speaking of endianness, the Allegro library (http://alleg.sf.net/)
solved that quite well by providing special file writing routines that
somewhat seamlessly replace standard fopen/fclose/fwrite/etc. For
example, there's pack_iputl() which writes a 4-byte integer using
"Intel" ordering, and pack_mputl() which writes one using "Motorola"
ordering. Most of my old Allegro programs just used pack_mputl() all
the time. It's great because on Intel it compiles into a macro that
switches the bytes around, but on the Mac it's just a wrapper for
fwrite, essentially. As far as file write speed went I never noticed
any kind of serious decreases.
~ C
Jesse Rusak
bundle.
Jesse Rusak
> But the windowmode thing didn't work for me? I tried a bunch of
> settings from one of the manual pages.
This works for me, in full screen, without the compile (after
compiling it once)
windowmode 0
automax 0
mount1 v3splash320.vpk
releasemode 1
> Speaking of endianness, the Allegro library (http://alleg.sf.net/)
> solved that quite well by providing special file writing routines that
> somewhat seamlessly replace standard fopen/fclose/fwrite/etc. For
> example, there's pack_iputl() which writes a 4-byte integer using
> "Intel" ordering, and pack_mputl() which writes one using "Motorola"
> ordering. Most of my old Allegro programs just used pack_mputl() all
> the time. It's great because on Intel it compiles into a macro that
> switches the bytes around, but on the Mac it's just a wrapper for
> fwrite, essentially. As far as file write speed went I never noticed
> any kind of serious decreases.
Cool - I do something similar with v3 (for loading map files, etc.),
but the compiled VC itself is kinda complex - it's just read in as a
binary blob and taken apart at runtime depending on the instructions.
I don't recall the exact details, but it seemed non-trivial to make
endian-neutral when I last looked at it. It would be pretty cool,
though.
Collin
what any other compiled source would be like. You would have to
understand the op codes to be able to know which things to byte swap.
The two possibilities are:
1. Make a function that understands all of the op codes and goes through
swapping bytes where necessary (not worth it IMO)
2. Make the runtime (which already understands all opcodes) do the
swapping while running. This is a lot easier but slows things down a little.
kattkieru
> bundle.
Oh okay. Like I said, either way works. I just prefer static libs
myself.
> This works for me, in full screen, without the compile (after
> compiling it once)
>
> windowmode 0
> automax 0
> mount1 v3splash320.vpk
> releasemode 1
I ran with that. I get full screen mode, but the Verge3 draw context
is in a 320x240 little box in the center of the 640x480 screen. Also,
when I got to load the game it kicks me out of full screen with an
error. ^_^;
Total side note: Qt4 is not as easy as advertised to get all up and
running. =/ Still moving forward.
andy
noticable on a 300MHz computer, let alone one that runs at 1GHz.
-- andy
Ben McGraw
> ...Fink?
Yeah, I dunno why they called it that, either. mac-apt-get would have
been better.
For right now, though, I don't think it'll be necessary for developers
to use it to compile the Mac version of V3. Most of the serious
dependencies go into SDL anyway.
> www.verge-rpg.com/svn/sully is now publically readable.
Rock on. I grabbed it today. Some of it works in my V3 Mac build by
just putting the app into the directory. ^-^ It's missing verge.cfg,
so it doesn't load as-is in SVN. There are also a number of save
games in SVN that might not need to be there?
> Email me and I'll set up read/write on the engine project for you,
> kattkieru.
I'll drop you a mail after this. I suppose I should also learn how to
use SVN, huh. Will that include write access to Sully?
By the by, the new Sully demo is *amazing* compared to the V2
version. Overworld map FTW! There're a lot of spots that throw up
errors (like the big red circle on the overworld -- click it and it
say something about no multiple windows yet and then crashes). But
the blending and the SNES-style transitions? Awesome.
The other thing that the demo brings up is the lack of true full-
screen in the mac version... There a simple way to get the screen to
stretch fully? Changing xres and yres in verge.cfg just shifts the
screen around. There're some other things too, like the big compile
at the beginning and the fact that, at least in the mac version,
tabbing out doesn't work and the intro compile can't be canceled,
like, at all. Might be even nicer if the screen changed a bit to show
the current file being compiled / loaded or something. Also: is there
a way to make the compiled files save out so that you don't have to
sit through the process again?
kattkieru
> little swamped lately. And now I'm sick. Well job, body.
Cheers mate. I hope things get better for you quick. There's no rush
right now; I'm not working directly on the Verge3 code, just on
getting it building properly. Actually that's not even entirely true;
I need to write the Mac build instructions because at this particular
moment in time everything seems peachy-keen, and I think Jesse added
the SDL stuff to the Mac folder already.
I've actually been spending my spare time attempting to wrangle a Qt-
based level editor together. Please don't mention it or anything;
I've run some promising tests but I've recently taken on a more
demanding job and time is becoming more difficult to come by.
However, once I have a proper test up and running I'll post something
downloadable to the list. I've got tiles drawing and all right now;
next is capturing user input. I have fairly grand plans, but it'll
all depend on how much time I have and how difficult getting the rest
done in Qt will be. (It's one insane system.)
> Why would you be writing to sully? Out of curiosity.
Minor Mac-related fixes as I come across them. I'm basically only
using Sully to test the Mac port when I can. I don't need Sully SVN
for the moment, although I wanted to add a verge.cfg file to SVN as
there wasn't one in there when I grabbed a copy of the tree.
> The big red circle (which for nostalgia's sake I *think* is windigone from
> The Silver Circle) it a testing trigger for the battle system. If that
> crashes on macs, well, it'd be nice to know why.
I'll give it another look-- I forget the exact error message right
now. The message that comes up the most, though, is something about
converting into a two digit number from something too large. When
that message comes up it kicks the user out of full screen, too.
Thanks again,
- Charles
Ben McGraw
Minor Mac-related fixes as I come across them. I'm basically only
using Sully to test the Mac port when I can. I don't need Sully SVN
for the moment, although I wanted to add a verge.cfg file to SVN as
there wasn't one in there when I grabbed a copy of the tree.
Jesse Rusak
> is in a 320x240 little box in the center of the 640x480 screen.
I think this is because when I ask SDL for a 320x240 full screen, it
barfs because your computer can't change to that natively. According
to the SDL docs, we get a 320x240 surface back anyway, stuck in the
middle of the screen. We could stick in a hack to never ask for a
320x240 directly (since I don't think we'll ever get it) and just ask
for a 640x480, which we can then scale up to. What do you think?
> I need to write the Mac build instructions because at this particular
> moment in time everything seems peachy-keen, and I think Jesse added
> the SDL stuff to the Mac folder already.
I haven't, actually. I remembered why we need to use a dylib - SDL is
LGPL, and since v3 is BSD, I think we need to link dynamically so
someone can replace the SDL lib if they want to. (Why would they want
to? I don't know.) I'll try to stick that in tonight.
> The big red circle (which for nostalgia's sake I *think* is
> windigone from
> The Silver Circle) it a testing trigger for the battle system. If
> that
> crashes on macs, well, it'd be nice to know why.
This crashes because SDL doesn't support more than one window. If
this is integral to sully's battle system we should, uh, think about
that.
> I've actually been spending my spare time attempting to wrangle a Qt-
> based level editor together.
Sounds like fun!
kattkieru
> their own .cfg not be overwritten. I suppose there should be a
> verge.cfg.example though >_>
Normally I'd agree that such is a good idea, but Sully won't load
without verge.cfg loading the splash pack. The VC craps out before
the Verge logo is ever seen.
~ Charles
Collin
>> I ran with that. I get full screen mode, but the Verge3 draw context
>> is in a 320x240 little box in the center of the 640x480 screen.
>>
>
> I think this is because when I ask SDL for a 320x240 full screen, it
> barfs because your computer can't change to that natively. According
> to the SDL docs, we get a 320x240 surface back anyway, stuck in the
> middle of the screen. We could stick in a hack to never ask for a
> 320x240 directly (since I don't think we'll ever get it) and just ask
> for a 640x480, which we can then scale up to. What do you think?
>
Well, you'd think a real pc could do that resolution. They used to and I
think modern cards still support VESA graphics. But, even if the machine
could it would still probably be better to never ask for less than
640x480 and just internally scale 2x to compensate. Granted, that will
look really blocky but there are clever algo's out there to fix that.
> This crashes because SDL doesn't support more than one window. If
> this is integral to sully's battle system we should, uh, think about
> that.
>
>
Yes, the SDL one window limit really sucks. It can only really be used
in one window at a time. I'd bet that it's still possible to create more
windows but it won't work in them. Technically it'd probably be possible
to create more windows anyway and then use tricks to make it work. One
could render SDL output to an offscreen buffer and then manually blit
output to multiple windows behind SDL's back. The problem is that SDL
will only be responding to events in the main window. This can be made
to work if the sub windows either 1. Only display things or 2. The main
window has code which takes it upon itself to process the events for the
new window and then pass the data back to the new window. In essence,
the way it would work is that the app would really be coded as if it
were one window but multiple windows would really be on screen.
Needless to say, it'll complicate things. Still, I think it would be
possible. The problem is that window creation will be different for each
platform.
Ben McGraw
Jesse Rusak wrote:
>> I ran with that. I get full screen mode, but the Verge3 draw context
>> is in a 320x240 little box in the center of the 640x480 screen.
>>
>
> I think this is because when I ask SDL for a 320x240 full screen, it
> barfs because your computer can't change to that natively. According
> to the SDL docs, we get a 320x240 surface back anyway, stuck in the
> middle of the screen. We could stick in a hack to never ask for a
> 320x240 directly (since I don't think we'll ever get it) and just ask
> for a 640x480, which we can then scale up to. What do you think?
>
Well, you'd think a real pc could do that resolution. They used to and I
think modern cards still support VESA graphics. But, even if the machine
could it would still probably be better to never ask for less than
640x480 and just internally scale 2x to compensate. Granted, that will
look really blocky but there are clever algo's out there to fix that.
Many ducats, doubloons, and/or deutsch marks to the man who puts in some better scaling code. Frankly, I do not ever think it should scale up to a non-square ratio. Doing a quick 2x/3x/4x inflate with blackbox on both sides for the remainder is far better than the hideous, and slow, alternative.
Once the straight-scale is in with style and panache, 2xsai/super eagle/fancy pancy interpolation filters could be added, but t'aint so important.
> This crashes because SDL doesn't support more than one window. If
> this is integral to sully's battle system we should, uh, think about
> that.
>
>
Yes, the SDL one window limit really sucks. It can only really be used
in one window at a time. I'd bet that it's still possible to create more
windows but it won't work in them. Technically it'd probably be possible
to create more windows anyway and then use tricks to make it work. One
could render SDL output to an offscreen buffer and then manually blit
output to multiple windows behind SDL's back. The problem is that SDL
will only be responding to events in the main window. This can be made
to work if the sub windows either 1. Only display things or 2. The main
window has code which takes it upon itself to process the events for the
new window and then pass the data back to the new window. In essence,
the way it would work is that the app would really be coded as if it
were one window but multiple windows would really be on screen.
The multiple windows thing is *not* vital to the battle system. I just utilized the dual window dojobbie to have a battlesystem stat console for debugging the battle process. It's meant to have a stat dump of every battle actor and the ability to switch between "normal time" and "manual battle-clock-tick-step-through" modes. The last bit's in, but I never got around to displaying the stats.
Needless to say, it'll complicate things. Still, I think it would be
possible. The problem is that window creation will be different for each
platform.
I think the subwindow creation thing is a silly, gimmicky feature that can be redacted from the codebase without really harming things. At the least, you can stub it all to rendering to some screen-sized image handle off in memory and just don't render it?
Jesse Rusak
>> and I
>> think modern cards still support VESA graphics. But, even if the
>> machine
>> could it would still probably be better to never ask for less than
>> 640x480 and just internally scale 2x to compensate. Granted, that
>> will
>> look really blocky but there are clever algo's out there to fix that.
>
> Many ducats, doubloons, and/or deutsch marks to the man who puts in
> some better scaling code. Frankly, I do not ever think it should
> scale up to a non-square ratio. Doing a quick 2x/3x/4x inflate
> with blackbox on both sides for the remainder is far better than
> the hideous, and slow, alternative.
>
> Once the straight-scale is in with style and panache, 2xsai/super
> eagle/fancy pancy interpolation filters could be added, but t'aint
> so important.
The mac build used to use GL scaling (which can be set to "nice
mode") to do exactly the blackbox stuff you describe. It had to be
removed, though, because of some internal slowness resulting, I
think, from converting from verge's pixel format to GL's every frame.
It looks like SDL can provide a list of possible window dimensions,
and some intelligent choosing of those and scaling might be a good
quick solution.
> > This crashes because SDL doesn't support more than one window. If
> > this is integral to sully's battle system we should, uh, think about
> > that.
> >
> >
> Yes, the SDL one window limit really sucks. <big snip>
This sounds a lot more complex to me than just using something (eg.
GLUT, QT, ?) that supports multiple windows. There's no point in
standardizing on SDL if we have to hack around it specially for every
platform.
> I think the subwindow creation thing is a silly, gimmicky feature
> that can be redacted from the codebase without really harming
> things. At the least, you can stub it all to rendering to some
> screen-sized image handle off in memory and just don't render it?
I'll look into the stubbing for the mac build.
- Jesse
Collin
> The mac build used to use GL scaling (which can be set to "nice
> mode") to do exactly the blackbox stuff you describe. It had to be
> removed, though, because of some internal slowness resulting, I
> think, from converting from verge's pixel format to GL's every frame.
> It looks like SDL can provide a list of possible window dimensions,
> and some intelligent choosing of those and scaling might be a good
> quick solution.
>
>
that was the problem. The problem was that uploading textures isn't that
terribly fast. On linux the opengl and verge pixel formats were the
same. There was no conversion just 'send it to the card'. But it was
still slow because changing textures has some overhead. It would have
been a LOT faster if all sprites and graphics had been uploaded to the
card beforehand and then rendered where they needed to be as textured
rectangles directly from the resident textures. But that would require
totally rewriting the verge rendering code. Not that it would be all
bad. OGL is cross platform standard and you'd get various nice things
basically for free (rotation, scaling, antialiasing, translucency, etc)
Jesse Rusak
On 24-May-07, at 7:33 AM, Collin wrote:
>
> Jesse Rusak wrote:
>> The mac build used to use GL scaling (which can be set to "nice
>> mode") to do exactly the blackbox stuff you describe. It had to be
>> removed, though, because of some internal slowness resulting, I
>> think, from converting from verge's pixel format to GL's every frame.
>> It looks like SDL can provide a list of possible window dimensions,
>> and some intelligent choosing of those and scaling might be a good
>> quick solution.
>>
>>
> I don't think that the conversion from verge's pixel format to
> opengl's
> that was the problem. The problem was that uploading textures isn't
> that
> terribly fast. On linux the opengl and verge pixel formats were the
> same. There was no conversion just 'send it to the card'. But it was
> still slow because changing textures has some overhead.
I did some profiling, and there were internal functions to convert
between texture formats taking up huge amounts of time (like > 50%
CPU). This could have been an artifact of the fact that it was
waiting on the GPU or transfer, though.
> It would have
> been a LOT faster if all sprites and graphics had been uploaded to the
> card beforehand and then rendered where they needed to be as textured
> rectangles directly from the resident textures. But that would require
> totally rewriting the verge rendering code. Not that it would be all
> bad. OGL is cross platform standard and you'd get various nice things
> basically for free (rotation, scaling, antialiasing, translucency,
> etc)
I've thought about this before; the only problem is that you
basically destroy the ability to do per-pixel peek/poke (especially
poke) or, at least, I don't know how to do that easily/quickly with
textures already on the card. (I think this is why ika has 2
different image formats - one for static images, and a "canvas" that
you can alter?)
Collin
>>
>> I don't think that the conversion from verge's pixel format to
>> opengl's
>> that was the problem. The problem was that uploading textures isn't
>> that
>> terribly fast. On linux the opengl and verge pixel formats were the
>> same. There was no conversion just 'send it to the card'. But it was
>> still slow because changing textures has some overhead.
>>
>
> I did some profiling, and there were internal functions to convert
> between texture formats taking up huge amounts of time (like > 50%
> CPU). This could have been an artifact of the fact that it was
> waiting on the GPU or transfer, though.
>
Hmm... I did profiling in linux and that didn't seem to be the case...
But each person's graphics card will act differently and different OS's
will do different things too... Still, maybe I just didn't recognize it
for what it was.
>
>> It would have
>> been a LOT faster if all sprites and graphics had been uploaded to the
>> card beforehand and then rendered where they needed to be as textured
>> rectangles directly from the resident textures. But that would require
>> totally rewriting the verge rendering code. Not that it would be all
>> bad. OGL is cross platform standard and you'd get various nice things
>> basically for free (rotation, scaling, antialiasing, translucency,
>> etc)
>>
>
> I've thought about this before; the only problem is that you
> basically destroy the ability to do per-pixel peek/poke (especially
> poke) or, at least, I don't know how to do that easily/quickly with
> textures already on the card. (I think this is why ika has 2
> different image formats - one for static images, and a "canvas" that
> you can alter?)
>
>
I think you've got the right idea there.You would still have the source
textures in system memory (or at least you still could.) Then you could
pixel peek into them but poking would require reuploading the texture.
So long as you didn't do that to 50 textures a frame you'd probably be
OK. So you'd have to always store system copies of the textures and work
locally then upload them to the card before the frame is rendered. It's
possible to do screen captures too to get that data but historically
getting data off of the card is really REALLY slow.
Ben McGraw
What should I get, software-wise, to get the ball rolling there?
Jesse Rusak
developer tools (ie XCode). That should come on one of the DVDs with
the computer. You can also download it from http://connect.apple.com/
(make free "online" account.)
Then there's SVN (I think that doesn't come installed). In terms of
other stuff, I suggest getting the 30 day demo of TextMate - it's a
very nice little code editor; I have a dumb little VC mode for it.
That's all I can think of for code-related vergedev.
kattkieru
Any time you have to install a 3rd-party OSS library it's usually the
way to go.
And I second TextMate; once you get over the learning curve and
realize just how powerful it is, you'll never code using anything
else. It's the first program I've used since freshman year of uni
that made me stop typing in emacs.
And if you, for whatever reason, decide to start developing using
Qt4.3, I would HIGHLY recommend you build it using the following:
./configure -qt-gif -qt-libtiff -qt-libpng -qt-libmng -qt-libjpeg
Saves a lot of headache.
~ Charles
On May 31, 10:10 pm, Jesse Rusak <jesse.ru...@gmail.com> wrote:
> Whoa! That's awesome. All you _need_ for development Apple's
> developer tools (ie XCode). That should come on one of the DVDs with
> the computer. You can also download it fromhttp://connect.apple.com/
Ben McGraw
PS: don't tell the windows guys I'm now polyoperous. They'll defenestrate me.
PPS: I ended up getting a mac mini dual core intel 1.6. I can still dev for the old chipsets, right? What about OS9? Anyone have stats as to saturation of old oses?
-uəq
kattkieru
I wanted to let you know that I am not, in fact, dead after having
been so enthusiastic at first. ^-^ New job, lots more work than I was
expecting.
SVN still isn't working for me, but I did send the mac build
instructions to Ben -- should I post a link on my site to get folks'
opinions?
I haven't been looking at the engine code much; I've been working
mostly on getting a tile editor going in Qt4. Things are looking
better - I've finally got a modifiable grid drawing, but it's
sloooooow. I've been trying to get the graphics scene itself to act
as one large bitmap, but in tests so far isn't not behaving as
expected.
Two quick questions:
- Is requiring openGL for the tile editor a faux pas? If not I'll
switch to that and just do it the slow, stupid way -- *it* works and
with OpenGL rendering it won't be an issue.
- Qt4 is GPL2, and Verge 3 is BSD... if I wanted to use the verge 3
map, etc., loading and saving code in my editor, would that be
possible?
~ Charles
Ben McGraw
Any software you make can be whatever license. You're only dealing with verge formats with an editor, not verge itself. Unless I'm a complete idiot, the GPL cannot "infect" verge via a 3rd party app.
-b
Shamus Peveril
Jesse Rusak
> Now, is there a standard installshield-like process for mac
> packages downloaded from the intertubes? I'm new to your fruity
> world.
Many apps come just like verge - just a .app that you put in
Applications. Most others use Apple's installer - you can make these
packages with the PackageMaker.app that lives in /Developer/
Applications/Utilities. Both often come in a disk image (.dmg -
think .zip) for compression and packaging.
> PS: don't tell the windows guys I'm now polyoperous. They'll
> defenestrate me.
Defenestration might be a good thing with operating systems. >_>
> PPS: I ended up getting a mac mini dual core intel 1.6. I can
> still dev for the old chipsets, right? What about OS9? Anyone
> have stats as to saturation of old oses?
You can still develop for the PPC chipset but you won't be able to
run OS 9, I don't think. As far as I know, Apple officially doesn't
do anything for people using OS 9.
Jesse Rusak
> mostly on getting a tile editor going in Qt4. Things are looking
> better - I've finally got a modifiable grid drawing, but it's
> sloooooow. I've been trying to get the graphics scene itself to act
> as one large bitmap, but in tests so far isn't not behaving as
> expected.
Sounds cool.
> Two quick questions:
> - Is requiring openGL for the tile editor a faux pas? If not I'll
> switch to that and just do it the slow, stupid way -- *it* works and
> with OpenGL rendering it won't be an issue.
I don't think requiring GL is a problem. Even oldish computers will
have basic GL support.
> - Qt4 is GPL2, and Verge 3 is BSD... if I wanted to use the verge 3
> map, etc., loading and saving code in my editor, would that be
> possible?
If I recall correctly (Wikipedia and the FSF (http://www.gnu.org/
philosophy/license-list.html) seem to say the same thing) you can
release BSD'd code as GPL code. But not the other way around. So you
could take verge code, incorporate it into something with a GPL
license and release it as GPL'd.