Show Posts

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

Messages - spathi

Pages: 1 2 [3] 4
C / C++ /C# / Re: Good Features for Sprite Library?
« on: April 06, 2012 »
That would certainly be reasonable to include.  I write in Blitz and it already has those things.  The sprite collision is noted for being slow, though.  Perhaps I could put in some sort of minimal bounding box code to cull the collisions, if it's not already in there...

Any other thoughts?  I am primarily looking for animation features.

Was thinking of having an editor where you could bind various entities to xy coordinates on the sprite, entities like sub-sprites (googly eyes, turrets) and particle emitters, which would all then translate and rotate along with the sprite. that is best done at an object level...

C / C++ /C# / Good Features for Sprite Library?
« on: March 29, 2012 »
Hey gents, I'm currently writing a small sprite library containing various animation functions.  I'm wondering if anyone has any ideas for functionality that I could include.

I have such things as fades, with function pointers to different ramping functions.

Ideally I would like all those ramps to be generic and usable for numerous different features, like smooth interpolation between color values.

There are also various types of bouncing and jiggling.

I'm just soliciting ideas so that I can put as much as possible into the library while I have the code fresh in my mind.

X server exporting windows to clients.  This should work with thin clients and should be great for compiling.  Rdist to maintain and update software on the clients.  I'd run Ubuntu or Debian (or whatever linux) on the desktops.

Any IT department that would run that sort of janky-ass windows citrix bullshit for a programming environment should all be sacked, there is simply no excuse whatsoever.

With X you can have a thin client solution on the cheap that will work.

Right now at this moment I am doing this, sort of.  I do not have a thin client for a desktop, rather a good Windows 7 gaming desktop, but I run Cygwin X exporting X sessions from my linux box.  The X sessions are very small and do not take much RAM at all on the client.

At least in academic computing environments you would think that IT departments would be savvy enough to not engage in such silliness when there are far better solutions.  You can have an excellent thin client setup (particularly if all clients are set up with distCC for distributed compiling, it will be super fast for everyone).

But you are not ever going to get there with windows and it's a fool's errand to even try.

Working on kid's games. 

Boring as hell to write but it's a gig.

General coding questions / LISP?
« on: January 29, 2012 »
Any LISP coders?  I am new to the language and it seems exceedingly interesting and potentially very powerful despite 30 years of imperative programming making it rather a bit of a bear to understand.  There are a number of great lecture courses on Youtube about it, specifically "Structure and Interpretation of Computer Programs," both the MIT and Stanford versions.  I've tried cracking lisp before and gave up-- I am a little farther this time.

Challenges & Competitions / Re: Game Competition?
« on: January 13, 2012 »
Demos always seemed to me like they were, well, demos of game engine technologies.  There are very few demos out there that couldn't be turned into games on their respective platforms without much effort, provided that you didn't have to adhere to a 4k limit or so.

Challenges & Competitions / Game Competition?
« on: January 12, 2012 »
Anyone interested in a retro (or anything) game competition?

Really I am selfish, I just want new games to play.

General chat / Re: Cash from Casual Games?
« on: January 04, 2012 »
I'm definitely going to do mobile ports, which is why I picked up Blitz Monkey (easy porting to five compile targets or something like that...) 

In some of the statistics I've seen there is a really good long-tail effect going on, where they might only be making $10 per month per game but that $10 extends over a period of years.

General chat / Cash from Casual Games?
« on: January 04, 2012 »
Is there any point these days in writing casual games for the portals, et cetera?  Does anyone make any money on that anymore?  If you release numerous games in a few styles, is it possible that it could be viable?

General chat / Re: Why are pixel reads so slow?
« on: January 04, 2012 »
Wow, I'm very interested in this.  I haven't dug into the Blitzmax source at all, and I should probably do so.  But I got Monkey and have been working with that (love it!)

The Blitz languages really put the fun back in programming.

Code: [Select]
'Blitzmax Font Stripper
' By SpayThee

' If you get this harmless error "D3DERR: Unable to lock render target surface" it means you are
' trying to draw a pixmap outside of the screen boundaries... the image needs to be large enough
' to accomodate the font strip it will make when generating the font image.

' These settings will work with this image:
' BUT!  You have to load it up in paint and save it as a bmp, because it won't like loading a gif...
' Save it in a ./media directory...


Global FONTSIZE:Int=16
Global FONTOUTPUTNAME:String = "fontstrip.png"
Local fontpixmap:TPixmap=LoadPixmap("media/062.bmp")  ' Font Name Goes Here
Local fontstrip:TImage=CreateImage(ORIGIMAGESIZEX*FONTSIZE,FONTSIZEY)  ' Create image the size of fontstrip
Global pixwindow:TPixmap
Global savepixmap:TPixmap

' The next string needs to contain the characters in the order they appear in the bitmap.
' This is used as a lookup string for fontprint()
Global characters:String="-.!0123456789:'(),? ABCDEFGHIJKLMNOPQRSTUVWXYZ"

'  This block of three FOR clauses chops up the bitmap and renders it all out as a strip.
'  It's three clauses because all of the bitmap fonts are different anyway so you have to jigger
'  this differently depending on how the font maker set his bitmap up.

For i = 0 To ORIGIMAGESIZEX Step 16  'Step expression must be constant!?
pixwindow = PixmapWindow(fontpixmap,i,0,FONTSIZE,FONTSIZE)
DrawPixmap pixwindow, i,0

For i = 0 To ORIGIMAGESIZEX Step 16
pixwindow = PixmapWindow(fontpixmap,i,FONTSIZE+1,FONTSIZE,FONTSIZE+1)
DrawPixmap pixwindow, i+320,0

For i = 0 To ORIGIMAGESIZEX Step 16
pixwindow = PixmapWindow(fontpixmap,i,FONTSIZE*2+2,FONTSIZE,FONTSIZE+2)
DrawPixmap pixwindow, i+640,0

' Save the stripfont so we don't need to go through all this rigamarole each time we want to load the font image.  Could also reorder
' the letters if you wanted to, if you had a bunch of fonts...  all these old demoscene fonts have all sorts of weird letter orders and fucked up
' conventions that they adhere to.

Local charmap:tmap=CreateMap()

'Driver, Test, Copper
Global ticks:Int=0

teststrip:TImage = CreateImage(480,fontsize,1,DYNAMICIMAGE|MASKEDIMAGE)

fontprint("COPPER TEXT... I MISS ROBOTRON",10,10)

'This chunk is to build the TImage for the copper.  Necessary because pixmaps won't
'allow you to draw in maskmode (that I know of)
'Major hackwork in order to allow you to get a mask image.

GrabImage teststrip,10,10 
SetColor 255,255,255
DrawRect 0,0,1024,480
SetColor 0,0,0
DrawImage teststrip,10,10
GrabImage teststrip,10,10

Local xorig:Int
Local yorig:Int
While Not KeyHit(KEY_ESCAPE)
SetColor 255,0,0
SetMaskColor 255,255,255
SetColor 1,0,0
DrawImage teststrip, 0+xorig,10+yorig
fontprint("-.!0123456789:'(),?", 10,10)
fontprint("JUST A LITTLE FONT DEMO", 10,46)
fontprint("NOT MUCH TO LOOK AT", 10,66)

' A very basic time-sliding copper
Function copperbar(ux:Int,uy:Int,lx:Int,ly:Int)
frequency = Sin(ticks)*25+50
For Local y:Int = uy To ly
SetColor 128*Sin(ticks *frequency +(y-uy)*50)+128,128*Cos(ticks *frequency +(y-uy)*50)+128,Rand(255)
DrawLine ux,y, lx,y
End Function

Function fontprint(stringtoprint:String,x:Int,y:Int)
' you will probably want to touppercase this string, otherwise it will not handle lowercase right
' unless the font is set up for that.  Or just type in all caps. 
For Local i:Int = 0 To stringtoprint.length-1
Local chartoprint:Int=characters.find(Chr(stringtoprint[i]))
If chartoprint = -1 chartoprint=13
DrawPixmap pixwindow, x+i*FONTSIZE,y
End Function

The image it uses is here...

General chat / Re: Why are pixel reads so slow?
« on: December 22, 2011 »
I'm talking about readpixel operations, eg in Blitzmax or SFML or SDL where they are all rather slow.  For instance it would be very fast to blit an 800x600 rectangular memory area to the screen, but reading that (eg with getimagerect() in Blitzmax or the similar in SFML) you wouldn't be able to do ten times per second. 

General chat / Why are pixel reads so slow?
« on: December 22, 2011 »
Why do pixel read operations tend to be so slow?  Is it because they are attempting to read from vram?

Could things be sped up with custom draw routines that also blit to an array as well as drawing to vram?  Then your pixel read operation would read from the array, which would contain identical information.  Your draws might be somewhat slower but your reads faster?

Projects / Re: Raymarching stuff
« on: December 21, 2011 »
That's gorgeous.  I need to get on this. 

As someone who did some programming on Crays and an SGI Reality engine, the cards these days are just flabbergastingly fast.

General chat / Relative Size of Demoscene?
« on: December 21, 2011 »
You know, it strikes me that the demoscene hasn't necessarily shrunk that much since the Amiga days-- or it might even have grown!  It seems like it's smaller in relation to everything else, but aren't there just a ton of things posted to Pouet?  The whole cracktro thing seems to have become a thing of the past-- is it possible that we could do something about that?  Scene releases from eg. Razor would go a long way toward popularizing the scene to a new generation.

Blitz / Re: Blitz Not Fast Enough?
« on: December 21, 2011 »
Even if it had some things wrong with it, I might stick with it anyway.  I find myself typing long classes and they work the first time, which they never do with C++ if I don't use my code generator.  There's something about the syntax of Blitz that is just very simple and good.

Blitz / Re: Blitz Not Fast Enough?
« on: December 21, 2011 »
I haven't been using it for long enough to really say for sure but from what I've seen of it, it's absolutely excellent, and you're right that you can of course do C externs, I did some of that today actually and it was easy as pie.

What's your take on the new BRL product, Monkey or whatever they are calling it now?

Blitz / Re: File Creation Issue
« on: December 20, 2011 »
Well if you have fifteen cups of coffee that will do it for sure. 

Coffee can actually kill you.  There are many cases of Russians in particular who have died from it because of their use of samovars which brew a thick black tar.

I think LSD probably causes some sort of receptor burn effect if you take too much of it or possibly for too sustained a period, there are many anecdotes about people who were never the same.  On the other hand that may not be true and we will never know... still I want to try a coding run on it [if I did that sort of thing which I never, ever, EVER would.]

Blitz / Blitz Not Fast Enough?
« on: December 20, 2011 »
I've noticed a number of comments from users and admins here (Shockwave I think, specifically) on the thread about software renderers and elsewhere, indicating that Blitz just isn't fast enough for writing fast software renderers.

Is this the case with Blitzmax or does it apply only to the older versions (Plus, Blitzbasic and 3D?)

Is Blitzmax worthwhile to stick with, for a few games at least, or will it be necessary to move to something faster?  It seems that Blitzmax is more than fast enough for any sort of retro title I'd be likely to do, especially since it can do OpenGL.  Is this the case?  I do know C and C++, except for templates, but I am completely blown away by Blitz and I would like to bring a couple of products to market with it.

That was extremely impressive.  The only thing it was missing was infinibobs.

I assume that was HTML5?  I'm starting to think that's going to be a viable platform for 2D games.

Pages: 1 2 [3] 4