Graphics and sounds artist needed for a game
Xavier
It's not about programming but well it's about creation so I thought
it was better to publish it here than somewhere else.
So, here is what it's all about.
Some 18 years ago I wanted to start a small France based company to
developp some games for the Archimedes.
I myself was not too bad at ARM programming, and I knew a few
completely ARM drugged programmers in the country.
At the time, we could get in touch thanks to the French minitel, a
slow machine, text and ugly graphics based.
Then life and the Acorn collapse changed it all.
Now, I'd like to finish this project started a long time ago.
You can know more here :
http://www.retrosoftware.co.uk/wiki/index.php/XTHOPAC_STUARC
Believe me, technically speaking, the result will have nothing to do
with what you ever experienced on the ARM2 machines, I've spent enough
time on my code for this.
Okay that's all very well but now I'm getting to the point :
I need some graphics, for just everything needed in a game like SWIV.
I also need a musician for musics (how surprising) and sounds.
It would be great if it could be a cooperative job with many people
working together.
I don't have any atmosphere or theme in my mind for the game.
It can be anything you like, and in fact the more different and
creative the levels will be, the happier I'll be, and I can get very
happy very quickly.
(You've never seen me dancing half naked in the pubs and errhh... well
that's a good thing ;-) ).
So, all you people who were crying seeing slow and ugly 2D games on
your Archimedes, wondering why on Earth there was nothing that clearly
surpassed the Amiga, after 20 years, you can help me and participate
to this 'cold blood revenge'.
I really hope to read from you soon.
If I don't find any people ready to DO sthing with me, I'll just drop
the project and spend more time in the pubs where I live (there is a
great O'Sullivan Irish pub where I live, ah ah ).
Martin Bazley
[snip]
> Okay that's all very well but now I'm getting to the point :
> I need some graphics, for just everything needed in a game like SWIV.
>
> I also need a musician for musics (how surprising) and sounds.
>
> It would be great if it could be a cooperative job with many people
> working together.
>
On the Icon Bar thread 'SWIV-a-like' [1] I offered to compose some
music, but the questions I asked there and never had answered still
apply.
Most importantly, exactly how many tracks do you want? I need hard
numbers!
How many levels will this game have, and how much music do I need to
compose for each one?
Will there need to be a specific 'mood' created for each level?
What kind of and how much other music will be required?
[1] http://www.iconbar.com/forums/viewthread.php?threadid=11341
--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
Xavier
wrote:
I'm sorry I thought I had been clear enough, about the specific pieces
of music needed for the different parts of the game.
I'm not escaping the icon bar thread coming here, it's just I see its
normal place here.
To answer your questions : so far I can't tell you how many levels
there'll be and how long there gonna be as it will depend on the
ability of the graphics artist to create the background tiles, maps
and the sprites.
A specific mood for the musics depending on the graphical atmosphere
is a plus, yes.
I see myself mostly as the programmer and animator of all this, and
not being an artist I want them to be creative and feel free as it's
going to be their work too, and not an 'add-on' to mine.
Thank you.
Best regards,
Xavier L.
Martin Bazley
> To answer your questions : so far I can't tell you how many levels
> there'll be and how long there gonna be as it will depend on the
> ability of the graphics artist to create the background tiles, maps
> and the sprites.
>
> A specific mood for the musics depending on the graphical atmosphere
> is a plus, yes.
>
> I see myself mostly as the programmer and animator of all this, and
> not being an artist I want them to be creative and feel free as it's
> going to be their work too, and not an 'add-on' to mine.
>
Hmm... all right then. So that leaves the title music, the high score
music, the game over music and the winning music. What are the
specifications for these - do they have to fit into a certain amount of
memory? I know you wanted 8 channels, but I'm afraid that if you use
QTM that's not going to be possible.
I'd rather get started as soon as possible, and I don't want to compose
something to be told it's unsuitable, so it would be best if you let me
know all necessary limits and instructions before I start.
--
__<^>__ Red sky in the morning: Shepherd's warning
/ _ _ \ Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
Xavier
wrote:
Hello and thank you for your interest.
8 channel musics for everything but the in game music would be great.
I see 2 MB machines as the target.
Once again the amount left for the music will depend on the amount of
tiles needed to build a background game, nulber of sprite etc ... even
though a disk access is sthing I'm considering (without pausing the
game for this, it's all the benefits of hardware MEMC video scrolling
with no sprites at this time in the game) but if you can do sthing
with 150 Kb of memory for the in-game action (4 channels) it should be
ok.
For the other parts where there is not much to handle for the ARM chip
(title, high score, winning music) where it would be 8 voices I think
you can consider 250 Kb for each music.
All this is going to be crunched anyway, and even though I think
people don't buy memory extensions for their old systems to play with,
I hope many of them bought a CF solution so we're not really limited
by the size of the 'loadable with needed without impact on the
gameplay' datas.
Cheers.
Xavier L.
Xavier
Back as I forgot sthing : if QTM can't handle 8 channel music we'll
keep it for 4 channels as it's the fastest and we'll use another
routine to output the 8 channels mod.
At these times in the game it's not necessary to get 50 frames per
sec. so any player, slow, will do.
Cheers,
XL.
Martin Bazley
> Back as I forgot sthing : if QTM can't handle 8 channel music we'll
> keep it for 4 channels as it's the fastest and we'll use another
> routine to output the 8 channels mod.
> At these times in the game it's not necessary to get 50 frames per
> sec. so any player, slow, will do.
Well, if you're willing to mix players, then the best one to get hold of
is probably DSymphonyPlayer, which will (unsurprisingly) load Digital
Symphony files of up to 8 channels. As this music is going to be
composed in Digital Symphony anyway and DSymphonyPlayer is considerably
faster (but less compatible) than the alternatives, this would seem the
best way to go.
--
__<^>__ "Your pet, our passion." - Purina
/ _ _ \ "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
Martin Bazley
> Hello and thank you for your interest.
> 8 channel musics for everything but the in game music would be great.
According to the QTM file format documentation, the only 8 channel
format it supports is StarTrekker. There is no way to produce a
StarTrekker file under RISC OS. Full stop.
The documents in question can be found here:
http://users.skynet.be/Andre.Timmermans/digitalcd/player/docs.zip
> I see 2 MB machines as the target.
> Once again the amount left for the music will depend on the amount of
> tiles needed to build a background game, nulber of sprite etc ... even
> though a disk access is sthing I'm considering (without pausing the
> game for this, it's all the benefits of hardware MEMC video scrolling
> with no sprites at this time in the game) but if you can do sthing
> with 150 Kb of memory for the in-game action (4 channels) it should be
> ok.
> For the other parts where there is not much to handle for the ARM chip
> (title, high score, winning music) where it would be 8 voices I think
> you can consider 250 Kb for each music.
150 KB and 250 KB sound like reasonable limits - have to be careful with
lengths of samples, of course, but given the quantity of music required
I have no intention of doing anything ambitious.
I'll start on a title tune (4 channels) as soon as I finish work on the
new releases of MRTools and MBBack (probably the weekend after next).
Alex Macfarlane Smith
> The following bytes were arranged on 10 Mar 2010 by Xavier :
>
>> To answer your questions : so far I can't tell you how many levels
>> there'll be and how long there gonna be as it will depend on the
>> ability of the graphics artist to create the background tiles, maps
>> and the sprites.
>>
>> A specific mood for the musics depending on the graphical atmosphere
>> is a plus, yes.
>>
>> I see myself mostly as the programmer and animator of all this, and
>> not being an artist I want them to be creative and feel free as it's
>> going to be their work too, and not an 'add-on' to mine.
>>
>
> Hmm... all right then. So that leaves the title music, the high score
> music, the game over music and the winning music. What are the
> specifications for these - do they have to fit into a certain amount of
> memory? I know you wanted 8 channels, but I'm afraid that if you use
> QTM that's not going to be possible.
>
The current version of QTM supports 8 channels as far as I'm aware (or
certainly I had one that would).
Alex.
Paul Stewart
I realise you are aiming for ARM2 machines, but any chance you can
make the game compatibale with modern (Risc PC, Iyonix and A9home)
systems? I'm sure all users of those systems would welcome a new
game.
Regards
--
Paul Stewart - Winslow, Buckingham, England.
(msn:pauls...@phawfaux.co.uk)
Xavier
Hello.
Well yes it shouldn't be a real problem.
I must say if the graphics artist could create 2 sets of his work, one
in hi res for the modern machines, and one in low res with the
disturbing false 256 colours, it wouldn't be very difficult to get 2
versions.
But, at 1st, my aim is to produce something astonishing for the old
and somehow limited 1st generation machines.
Also, thanks to the ARM7500 technical docs, I know how to do a
hardware scrolling for the RISC PC, but I've never found, so far, any
docs to know how to do it on the Iyonix (or the A9).
And please don't tell me about librairies blabla I reject all this
layer things which slow down the machines and prevent me from
understanding theirs guts : I want the real, direct, fast, hardware
solutions to do it.
Cheers,
Xavier L.
TomWalker
> Also, thanks to the ARM7500 technical docs, I know how to do a
> hardware scrolling for the RISC PC, but I've never found, so far, any
> docs to know how to do it on the Iyonix (or the A9).
For Iyonix you're probably best off looking at old VGA docs. Though
these might not really apply much when in SVGA modes on the Nvidia
cards.
> And please don't tell me about librairies blabla I reject all this
> layer things which slow down the machines and prevent me from
> understanding theirs guts : I want the real, direct, fast, hardware
> solutions to do it.
On newer machines you're not really going to loose much going for a
purely software solution, and it means you don't have to test on all
this newer hardware. It's not as if the OS is going to slow a game
aimed at ARM250 much.
Besides, I think in some sprite heavy situations, a purely software
solution might actually be faster than using hardware scrolling.
Tom
Martin Bazley
It certainly supports 8 channels, but the only format with 8 channel
support which it understands is not one with any support at all on RISC
OS.
Peter Naulls
> On 12 mar, 14:01, Paul Stewart <paulstew...@phawfaux.co.uk> wrote:
>> Hi Xavier,
>>
>> I realise you are aiming for ARM2 machines, but any chance you can
>> make the game compatibale with modern (Risc PC, Iyonix and A9home)
>> systems? I'm sure all users of those systems would welcome a new
>> game.
>>
>> Regards
>> --
>> Paul Stewart - Winslow, Buckingham, England.
>> (msn:paulstew...@phawfaux.co.uk)
>
If we are going to have more numerous posts from you, please at
least learn to finally snip signatures.
Thanks.
nytrex
> Back as I forgot sthing : if QTM can't handle 8 channel music we'll
> keep it for 4 channels as it's the fastest and we'll use another
> routine to output the 8 channels mod.
> At these times in the game it's not necessary to get 50 frames per
> sec. so any player, slow, will do.
> Cheers,
> XL.
I've been following your ambitious shoot-em up with interest for a
while now, and am keen to see it progress, so I am going to write my
first tracker song (in a long time) and see how it turns out. I've
also contacted two rather good musicians to see if they are interested
in wiriting some music for it. One you all probably know, the other is
only known on the PC demoscene circuit. Hopefully hear something back
from them soon.
There is also a module that plays back FastTracker2 (XM) files on RISC
OS, but I am unsure how much CPU cycles it takes. But that would open
up to 32 channels of music (in theory).
Martin Bazley
>
> I've been following your ambitious shoot-em up with interest for a
> while now, and am keen to see it progress, so I am going to write my
> first tracker song (in a long time) and see how it turns out. I've
> also contacted two rather good musicians to see if they are interested
> in wiriting some music for it. One you all probably know, the other is
> only known on the PC demoscene circuit. Hopefully hear something back
> from them soon.
>
Good to hear!
One thing, though - if there are going to be multiple musicians working
on this, we really need to coordinate our efforts. It's no good if
everybody writes different songs for the same in-game function! I
personally think it would be a good idea to hold off anything too
ambitious until we know exactly what types of levels we're going to be
writing for (fire, water, space, etc.) - which probably means getting in
touch with whoever's going to be in charge of the graphics as well.
> There is also a module that plays back FastTracker2 (XM) files on RISC
> OS, but I am unsure how much CPU cycles it takes. But that would open
> up to 32 channels of music (in theory).
I think you're probably thinking of TimPlayer, undoubtedly the slowest
of the lot. The absolute limit on an ARM710 is around 12 channels (32
channels is quite out of the question), which takes about 90% of
processor time, so I shudder to think how it would perform on an ARM2 -
especially at the same time as multiple processor-intensive game-related
tasks! Maybe one channel would do the trick? :-)
It may be possible to obtain a copy of XprMod - I'm not sure how fast
that one is. Probably faster, but don't expect anything like 32
channels.
--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
Xavier
Peter.
Please take your pills and learn not to be a pedantic arrogant prat.
If you find my posts unreadable, do sthing else like running your own
board where you'll be able to accept people as boring as you are.
There must be a couple left, so start a private club.
Xavier
wrote:
> The following bytes were arranged on 13 Mar 2010 by nytrex :
>
>
>
> > I've been following your ambitious shoot-em up with interest for a
> > while now, and am keen to see it progress, so I am going to write my
> > first tracker song (in a long time) and see how it turns out. I've
> > also contacted two rather good musicians to see if they are interested
> > in wiriting some music for it. One you all probably know, the other is
> > only known on the PC demoscene circuit. Hopefully hear something back
> > from them soon.
>
> Good to hear!
>
> One thing, though - if there are going to be multiple musicians working
> on this, we really need to coordinate our efforts. It's no good if
> everybody writes different songs for the same in-game function! I
> personally think it would be a good idea to hold off anything too
> ambitious until we know exactly what types of levels we're going to be
> writing for (fire, water, space, etc.) - which probably means getting in
> touch with whoever's going to be in charge of the graphics as well.
>
You're perfetly right.
So far I've got nobody for the graphics.
> > There is also a module that plays back FastTracker2 (XM) files on RISC
> > OS, but I am unsure how much CPU cycles it takes. But that would open
> > up to 32 channels of music (in theory).
>
Had never heard of it, sounds interesing.
> I think you're probably thinking of TimPlayer, undoubtedly the slowest
> of the lot. The absolute limit on an ARM710 is around 12 channels (32
> channels is quite out of the question), which takes about 90% of
> processor time, so I shudder to think how it would perform on an ARM2 -
> especially at the same time as multiple processor-intensive game-related
> tasks! Maybe one channel would do the trick? :-)
>
Hello.
As I said during 'action time' the music must be 4 channels.
It's for th other parts where more channels can be of interest and
feasible.
Especially if we consider the game will be installed on a hard drive
as today it's become so cheap to upgrade one's machine with a CF card
solution.
> It may be possible to obtain a copy of XprMod - I'm not sure how fast
> that one is. Probably faster, but don't expect anything like 32
> channels.
>
> --
Look Peter :
Peter Naulls
> Peter.
>
> Please take your pills and learn not to be a pedantic arrogant prat.
I'm not. I'm asking you to follow standard usenet etiquette. I
didn't feel the need to insult, or post numerous follow ups saying
nothing.
Since you're unable to do this, and restrain yourself, I strongly
recommend that help not be offered by anyone to Xavier until he
learns some manners. He is after all, asking for free advice.
Please don't bother to reply.
Xavier
Go to hell poor being.
You're just a nuisance wherever you post with your psychorigid fascist
like behaviour.
I utterly despise you and your siblings, who think they are entitled
to 'rule' and judge other people for such inconsistent details.
Find a rope and use it, you'll do at last sthing good to yourself and
the others.
nytrex
> > One thing, though - if there are going to be multiple musicians working
> > on this, we really need to coordinate our efforts. It's no good if
> > everybody writes different songs for the same in-game function! I
> > personally think it would be a good idea to hold off anything too
> > ambitious until we know exactly what types of levels we're going to be
> > writing for (fire, water, space, etc.) - which probably means getting in
> > touch with whoever's going to be in charge of the graphics as well.
You are probably right that it all needs coordinating, but for me its
a good idea to have more music than whats required, so you have the
option of choice when finalising things. Its quite possible, that my
music may not be up to standard and may not be used, which mean that
having more to fall back on is definetly better.
I'll keep in touch.
Peter Naulls
> On 13 mar, 17:08, Peter Naulls <pe...@chocky.org> wrote:
> You're just a nuisance wherever you post with your psychorigid fascist
> like behaviour.
Close enough. I invoke Godwin's law. Now there's really no need for
anyone to reply.
Steve Fryatt
<ba4795d5-b219-4b83...@q23g2000yqd.googlegroups.com>:
> Go to hell poor being. You're just a nuisance wherever you post with your
> psychorigid fascist like behaviour.
You're being asked to follow basic netiquette; please take your insults
elsewhere, as this group is not the place for them.
--
Steve Fryatt - Leeds, England
Xavier
> On Mar 12, 3:24 pm, Xavier <xlta...@gmail.com> wrote:
>
> > Also, thanks to the ARM7500 technical docs, I know how to do a
> > hardware scrolling for the RISC PC, but I've never found, so far, any
> > docs to know how to do it on the Iyonix (or the A9).
>
> For Iyonix you're probably best off looking at old VGA docs. Though
> these might not really apply much when in SVGA modes on the Nvidia
> cards.
>
scrolling.
> > And please don't tell me about librairies blabla I reject all this
> > layer things which slow down the machines and prevent me from
> > understanding theirs guts : I want the real, direct, fast, hardware
> > solutions to do it.
>
> On newer machines you're not really going to loose much going for a
> purely software solution, and it means you don't have to test on all
> this newer hardware. It's not as if the OS is going to slow a game
> aimed at ARM250 much.
>
> Besides, I think in some sprite heavy situations, a purely software
> solution might actually be faster than using hardware scrolling.
>
Err... No, it's the beauty of my routines : even with a screen crammed
with sprites, I still saves a lot of cycles with hard scrolling and my
own plotting/unplotting routines ...
TomWalker
> scrolling.
Yes they will. The Nvidia card in the Iyonix is SVGA but the native
register docs are not available. So the only option is to revert to
VGA and use mode-X hardware scrolling.
> Err... No, it's the beauty of my routines : even with a screen crammed
> with sprites, I still saves a lot of cycles with hard scrolling and my
> own plotting/unplotting routines ...
I think the tradeoff is whether it's faster to just do a straight copy
then plot sprites, verses unplotting sprites then storing background
then plotting sprites again.
Tom
Xavier
> > No, VGA or mode X will not help me understand how I get hardware
> > scrolling.
>
> Yes they will. The Nvidia card in the Iyonix is SVGA but the native
> register docs are not available. So the only option is to revert to
> VGA and use mode-X hardware scrolling.
>
Well... I'm not that sure... I can be wrong but I think the mode-X is
simply not supported anymore ith recent graphics card.
> > Err... No, it's the beauty of my routines : even with a screen crammed
> > with sprites, I still saves a lot of cycles with hard scrolling and my
> > own plotting/unplotting routines ...
>
> I think the tradeoff is whether it's faster to just do a straight copy
> then plot sprites, verses unplotting sprites then storing background
> then plotting sprites again.
>
I can tell you if you're using hardware scrolling 'storing background'
is done in a very cycles-cost effective manner... and it's all the
beauty of it.
Furthermore if you revisit the concept of unplotting sprites you can
gain 80% CPU cycles in comparison with the normal, lazy way.
Have a look at the bugs in my demo, seing them you'll quickly
understand what I mean, and how I can plot huge sprites on a scrolling
background, with 50 frames per second ...
http://www.retrosoftware.co.uk/wiki/index.php/XTHOPAC_STUARC
Cheers.
TomWalker
> On 17 mar, 12:29, TomWalker <tommowal...@gmail.com> wrote:
> > Yes they will. The Nvidia card in the Iyonix is SVGA but the native
> > register docs are not available. So the only option is to revert to
> > VGA and use mode-X hardware scrolling.
>
> Well... I'm not that sure... I can be wrong but I think the mode-X is
> simply not supported anymore ith recent graphics card.
Should be - it's needed for VGA compatibility. Which every GeForce is.
Playing with mode-X, though, will _definitely_ be slower than just
doing everything in software.
> I can tell you if you're using hardware scrolling 'storing background'
> is done in a very cycles-cost effective manner... and it's all the
> beauty of it.
> Furthermore if you revisit the concept of unplotting sprites you can
> gain 80% CPU cycles in comparison with the normal, lazy way.
>
> Have a look at the bugs in my demo, seing them you'll quickly
> understand what I mean, and how I can plot huge sprites on a scrolling
> background, with 50 frames per second
I've just disassembled your demo. Compiled sprites I could have
guessed, though not very good in terms of memory usage (and remind me
never to let you anywhere near a cache). The lack of clipping makes
sense - I've been toying with that, expanding the border to cover the
resulting mess.
I'm guessing you're only unplotting round the edges of the big sprite?
That would work, but would limit the shape of said sprite (also you'd
never be able to clip it). I can't think of many shooters with big
spherical enemies - Gradius 3 maybe, but they were transparent in the
middle.
Tom
Xavier
> On Mar 19, 2:52 pm, Xavier <xlta...@gmail.com> wrote:
>
> > On 17 mar, 12:29, TomWalker <tommowal...@gmail.com> wrote:
> > > Yes they will. The Nvidia card in the Iyonix is SVGA but the native
> > > register docs are not available. So the only option is to revert to
> > > VGA and use mode-X hardware scrolling.
>
> > Well... I'm not that sure... I can be wrong but I think the mode-X is
> > simply not supported anymore ith recent graphics card.
>
> Should be - it's needed for VGA compatibility. Which every GeForce is.
>
I've read somewhere it's been put aside.
If I'm not wrong, the pixels displayed on screen where not contiguous
in the VGA card memory with mode X activated, and as it's been used
only for old games, the newest card kept the VGA 'linear'
compatibility only.
If you've got some links to prove me I'm wrong, I'll be happy to read
them (you see I'm not stubborn and always happy to learn, I don't see
debating as a way to show off or please my ego).
Cheers,
Xavier.
Xavier
> I've just disassembled your demo. Compiled sprites I could have
> guessed, though not very good in terms of memory usage (and remind me
> never to let you anywhere near a cache). The lack of clipping makes
> sense - I've been toying with that, expanding the border to cover the
> resulting mess.
>
Well there is a price to pay and with a 2 Mb machine no problem.
Cache ? What is that on an ARM2 machine ?
The sequel to these old routines is far far better and much much less
memory consuming.
With a 15 to 20% speed increase for plotting and 75% increase for
unplotting. (the latest figure is easy to understand).
> I'm guessing you're only unplotting round the edges of the big sprite?
Don't guess you miserable being or I call Peter ;-)
And the answer is 'no' and an even bigger 'no' with my new set of
routines. ;-)
> That would work, but would limit the shape of said sprite (also you'd
> never be able to clip it). I can't think of many shooters with big
> spherical enemies - Gradius 3 maybe, but they were transparent in the
> middle.
>
I don't have these limitations with my new set of routines, it's why I
can tell you this old demo was just a beta product and I never wanted
to release it, as it was really far from could be achieved.
Prepare your debugger for my next releases ...
Cheers,
Xavier L.
TomWalker
> On 19 mar, 17:52, TomWalker <tommowal...@gmail.com> wrote:
> > Should be - it's needed for VGA compatibility. Which every GeForce is.
>
> No, I don't think so. Mode-X is a subset of VGA and I really think
> I've read somewhere it's been put aside.
Mode-X is (depending on how you look at it) mode 12h with the
sequencer set for 256 colour mode, or mode 13h with chain-4 disabled.
You can't not support mode-X without breaking one of those two modes,
it's just a side effect of having both 16 colour bitplanar and 256
colour chunky modes on the same card.
I can confirm, at the very least, that the GF 6600 series supports it.
And the card in the Iyonix is older than that.
Tom
Xavier
Okay thank you, I was wrong.