946
music/sound / Re: Don't stop the user music on devices under demmand
« on: 2010-Jun-28 »ok, I think I will make it, that if the iPod is on, the PLAYMUSIC commands will be ignored and iPod is played. Is that OK?Yes! This would be great.
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.
948
GLBasic - en / Re: iPhone Compilation Without A Mac
« on: 2010-Jun-18 »
Thanks MrTAToad and Slydog. Hmm, so 10.5 might be possible after all. Pity the G4 I was offered doesn't meet the minimum specs!
You know, if I wasn't a 100% law abiding citizen and didn't do everything by the book I would be tempted to stick Snow Leopard on a USB drive and run it from my netbook, which happens to have compatible hardware. Just for the purposes of compiling iPhone apps that would have saved me a lot of money, if I was going to do it, which I'm not.
[edit] From http://en.wikipedia.org/wiki/IPhone_SDK:-
"The SDK requires an Intel Mac running Mac OS X Leopard or later. Other operating systems, including Microsoft Windows and older versions of Mac OS X, are not supported."
I don't know how much to trust the quote from above. There was no citation.
You know, if I wasn't a 100% law abiding citizen and didn't do everything by the book I would be tempted to stick Snow Leopard on a USB drive and run it from my netbook, which happens to have compatible hardware. Just for the purposes of compiling iPhone apps that would have saved me a lot of money, if I was going to do it, which I'm not.
[edit] From http://en.wikipedia.org/wiki/IPhone_SDK:-
"The SDK requires an Intel Mac running Mac OS X Leopard or later. Other operating systems, including Microsoft Windows and older versions of Mac OS X, are not supported."
I don't know how much to trust the quote from above. There was no citation.
949
GLBasic - en / Re: iPhone Compilation Without A Mac
« on: 2010-Jun-18 »
Argh, dammit! I just found out I need Snow Leopard to compile with the iPhone SDK.
I was planning on upgrading an ancient G4 Power Mac to OS X Tiger just to compile for iPhone. That would only cost me $17 so it seemed like a great solution.
There is no way I can afford a Snow Leopard Mac right now. I guess I'll use someone else's Mac instead.
:'(
I was planning on upgrading an ancient G4 Power Mac to OS X Tiger just to compile for iPhone. That would only cost me $17 so it seemed like a great solution.
There is no way I can afford a Snow Leopard Mac right now. I guess I'll use someone else's Mac instead.
:'(
950
GLBasic - en / Re: Piracy
« on: 2010-Jun-06 »
fjsantosb how has Exodus been cracked? Was there copy protection that has been removed by a hacker? Or was a full working version shared online?
I don't think piracy can be stopped for one player games. It can only be reduced.
I believe most people pirate software because:-
Some possible ways to help reduce piracy:-
On that last point, Exodus only costs $1.99. Almost everyone I have talked to feels that $1 or $2 is like nothing and are willing to pay it. So...the pirates showing up on your server are Scrooge for not paying! They're probably people who would not pay for anything! In other words I don't think these people are potentially real customers that you are losing. Most likely they download cracked software as habit and will just play whatever they can get their hands on.
Good luck fjsantosb
I don't think piracy can be stopped for one player games. It can only be reduced.
I believe most people pirate software because:-
- They feel they are poor and can't afford to spend on software.
- It is a habit they have formed.
- It gives them a reward of feeling rebellious & smart. They feel they "win" when they get something for free.
Some possible ways to help reduce piracy:-
- Make it harder to pirate by using sort of copy protection.
- Offer additional incentives for people to have a real licensed version instead of pirated version.
- Try to make people somehow sympathetic with your software company. If they like you, they will want to reward you.
- Provide a free "lite" version or similar. If you give something of value away for free and (some) people will have a sense of reciprocity.
- Aim your game at a target audience who are not typically known to be technically proficient enough to pirate software.
- Generally make it more effort to pirate the game than pay for it. Pricing is important with this.
On that last point, Exodus only costs $1.99. Almost everyone I have talked to feels that $1 or $2 is like nothing and are willing to pay it. So...the pirates showing up on your server are Scrooge for not paying! They're probably people who would not pay for anything! In other words I don't think these people are potentially real customers that you are losing. Most likely they download cracked software as habit and will just play whatever they can get their hands on.
Good luck fjsantosb
951
Off Topic / Re: sculptris
« on: 2010-Jun-02 »
Well, I just discovered SFXR. Very useful proggy. DrPetter is awesome.
Ian, thanks.
I'm actually changing the look to "cute" seaside creatures and changing the background to a cartoon-ish beach rock pool. I've been told it has to be cute or it might stress people out!
Ian, thanks.
I'm actually changing the look to "cute" seaside creatures and changing the background to a cartoon-ish beach rock pool. I've been told it has to be cute or it might stress people out!
952
GLBasic - en / Re: Style of coding
« on: 2010-Jun-01 »
I wouldn't use functions for short simple stuff. No need. However, with anything large & complex functions make coding a lot easier. Also you can fold functions in the editor which also helps with visual organisation. I need help with staying organised because otherwise I will produce very messy noodle-tangled code which becomes hard to debug or understand. 
If you don't use functions then you don't need to declare variables as global because they'll automatically be assigned that way. However, you probably should declare them as global because its a good habit.
The way you declare an array to begin with makes it global. e.g.:-
GLOBAL fighter_combo[] // Otherwise LOCAL fighter_combo[] if used inside a function and not needed to be accessed outside
DIM fighter_combo[14][8]
If you do not declare it GLOBAL to begin with then it is implicitly made global.
If you don't use functions then you don't need to declare variables as global because they'll automatically be assigned that way. However, you probably should declare them as global because its a good habit.
The way you declare an array to begin with makes it global. e.g.:-
GLOBAL fighter_combo[] // Otherwise LOCAL fighter_combo[] if used inside a function and not needed to be accessed outside
DIM fighter_combo[14][8]
If you do not declare it GLOBAL to begin with then it is implicitly made global.
953
Off Topic / Re: sculptris
« on: 2010-May-31 »
I love this app. Its sooooo easy to use. Even a non-artist like me can create interesting stuff with it.
As an example I used Sculptris to quickly create some critters for an upcoming puzzle game I'm working on:-
Ocean, post-processing for GLB would be a challenge. The polygon count is huge even for simple sculptures. I suppose in theory you could import the files into Blender, reduce the complexity and export to something like AC3D for final post-processing before getting them in your GLBasic apps. Personally I'd rather just use things like Sculptris to generate 2D sprites or nice title screens.
As an example I used Sculptris to quickly create some critters for an upcoming puzzle game I'm working on:-
Ocean, post-processing for GLB would be a challenge. The polygon count is huge even for simple sculptures. I suppose in theory you could import the files into Blender, reduce the complexity and export to something like AC3D for final post-processing before getting them in your GLBasic apps. Personally I'd rather just use things like Sculptris to generate 2D sprites or nice title screens.
955
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-30 »
Thanks Ian! Yes, the scaling is probably the most significant thing.
Just now I did a whole series of tests and found that scaling is particularly expensive on these old Intel onboard graphics chipsets. Rotating is less expensive but still more expensive than simply drawing an non-rotated sprite twice. Oh and it makes no real difference if smooth shading is off or on; scaling is still slow. Whole screen scaling in particular will hugely drop fps from my tests. Despite having a slow Celeron processor my GF's computer is much quicker for scaling (and other 2D tasks) because "Intel Extreme Graphics 2" has better hardware scaling support than my computers.
Mystery solved!
bigsofty I knew these old Intel GFX chipsets weren't very good but just how bad they really are has surprised me. Most current and older netbooks will have them as well as some older PCs. This is something I'll have to consider carefully since I want anything I write to work smoothly using my netbook as the bottom line.
Again, if anyone wants to know how their apps perform on really crap PCs, that's obviously my speciality.
Just now I did a whole series of tests and found that scaling is particularly expensive on these old Intel onboard graphics chipsets. Rotating is less expensive but still more expensive than simply drawing an non-rotated sprite twice. Oh and it makes no real difference if smooth shading is off or on; scaling is still slow. Whole screen scaling in particular will hugely drop fps from my tests. Despite having a slow Celeron processor my GF's computer is much quicker for scaling (and other 2D tasks) because "Intel Extreme Graphics 2" has better hardware scaling support than my computers.
Mystery solved!
bigsofty I knew these old Intel GFX chipsets weren't very good but just how bad they really are has surprised me. Most current and older netbooks will have them as well as some older PCs. This is something I'll have to consider carefully since I want anything I write to work smoothly using my netbook as the bottom line.
Again, if anyone wants to know how their apps perform on really crap PCs, that's obviously my speciality.
956
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-28 »
OpenGL drivers come as part of the standard Intel graphics drivers for the chipsets I've been looking at, so yes. I've also made sure OpenGL settings are matched on each computer.
GF's laptop chipset is the Intel Extreme Graphics 2 variety.
I guess if anyone needs someone to test their apps work ok on old or under-powered PCs, I'm your man.
GF's laptop chipset is the Intel Extreme Graphics 2 variety.
I guess if anyone needs someone to test their apps work ok on old or under-powered PCs, I'm your man.
957
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-28 »
That's a good tip Ocean. In this case my girlfriend's laptop has half the video memory, just 64mb, but now I've had a chance to look at my girlfriend's laptop in person it turns out it has a different chipset! She didn't actually check, she just assumed it was the same.
Incidentally, I've just discovered if I run any full screen GLBasic app on my girlfriend's laptop there is another problem. After the app closes the desktop icons and some menu/system/window icons are corrupted. Repairing or deleting the icon cache doesn't help (but a restart fixes it). I've updated the drivers but the problem remains.
This is a summary of what I've discovered:-
Could be OpenGL driver bug for Intel chipsets or could be something with GLBasic. I just don't know.
Ian, I know you don't want to release your demo code but if you could email it to me privately I promise not to let anyone have it. I just desperately want to discover what it is that makes it run slow on my Eee 901 netbook (and others). The DRAWSPRITE slowness by itself doesn't seem enough to explain what's happening.
Incidentally, I've just discovered if I run any full screen GLBasic app on my girlfriend's laptop there is another problem. After the app closes the desktop icons and some menu/system/window icons are corrupted. Repairing or deleting the icon cache doesn't help (but a restart fixes it). I've updated the drivers but the problem remains.
This is a summary of what I've discovered:-
- Computers I've tested so far with Intel chipsets 82845G, 82915G and 945GSE are slow with DRAWSPRITE and can't run Ian's SOTB demo with full frame-rate (for whatever reason).
- A laptop with Intel chipset 82852/82855 doesn't have the same problem as above but corrupt icons occur after full-screen GLBasic apps have been run.
Could be OpenGL driver bug for Intel chipsets or could be something with GLBasic. I just don't know.
Ian, I know you don't want to release your demo code but if you could email it to me privately I promise not to let anyone have it. I just desperately want to discover what it is that makes it run slow on my Eee 901 netbook (and others). The DRAWSPRITE slowness by itself doesn't seem enough to explain what's happening.
958
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-27 »
Ian, your SOTB demo runs on my girlfriend's old Celeron laptop just fine - full fps as expected. She has the same standard Intel onboard graphics to me. However, I got the same fps drop on another Win XP computer I tested this morning. Weird.
What I am certain of is that calling DRAWSPRITE is very cpu expensive on my PCs regardless of how large the sprite is. I know this because if I use my girlfriend's laptop calling DRAWSPRITE is not at all expensive for small sprites - I can call it 800 times per frame without any slowdown whatsoever. On my PCs doing the same thing destroys my refresh rate with a vengeance. I don't know why this is happening because they don't behave oddly with other programs, just GLBasic compiled programs.
Anyway, there is definitely something about my PCs that means your demo runs very slowly. If it isn't the DRAWSPRITE problem then it is some other problem. I can't even make a guess what it would be without seeing your code but I have made a SOTB thingy myself to demonstrate that its possible to get something like you did working very fast on my underpowered Eee netbook. My SOTB thingy works with a great deal of cpu power to spare. I've included the code in the attached zip file so if you want you could take a look and see if there is anything obvious that points to why my demo works OK on my PCs and yours doesn't.
Edit: Sorry for not posting anything until today. I got carried away last night and ended up writing a little rehash of a SOTB song in Fruity Loops for my demo
[attachment deleted by admin]
What I am certain of is that calling DRAWSPRITE is very cpu expensive on my PCs regardless of how large the sprite is. I know this because if I use my girlfriend's laptop calling DRAWSPRITE is not at all expensive for small sprites - I can call it 800 times per frame without any slowdown whatsoever. On my PCs doing the same thing destroys my refresh rate with a vengeance. I don't know why this is happening because they don't behave oddly with other programs, just GLBasic compiled programs.
Anyway, there is definitely something about my PCs that means your demo runs very slowly. If it isn't the DRAWSPRITE problem then it is some other problem. I can't even make a guess what it would be without seeing your code but I have made a SOTB thingy myself to demonstrate that its possible to get something like you did working very fast on my underpowered Eee netbook. My SOTB thingy works with a great deal of cpu power to spare. I've included the code in the attached zip file so if you want you could take a look and see if there is anything obvious that points to why my demo works OK on my PCs and yours doesn't.
Edit: Sorry for not posting anything until today. I got carried away last night and ended up writing a little rehash of a SOTB song in Fruity Loops for my demo
[attachment deleted by admin]
959
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-26 »Well, all I can say is -
...
If a Wiz can do this, why on earth can't your pc?
Heheh. I'm not sure, but I know that through my own experiments I've found that calling DRAWANIM and DRAWSPRITE has a huge CPU cost when GLBasic compiled for PC regardless of the size of the sprite. The more times you call these routines the slower the PC code will run. How big or small the sprites are is insignificant next to the cost of using DRAWANIM in the first place. Try covering a screen with 32 x 32 sprites compared to 320 x 320 sprites and you may see the same difference on the PC that I am. I may be wrong about this - it might be something to do with my WinXP PCs here - but I've already started to adjust my routines accordingly because I was using line by line rendering in places and now they run a lot faster.
I've got to go to work now but when I get in a few hours I'll write a Shadow of the Beast parallax scrolling demo using minimum DRAWSPRITE calls. I'm sure I can up the framerate to 60fps and far beyond even with many more layers of parallax. We'll see. I'll upload the demo and the code even if it doesn't work out.
960
GLBasic - en / Re: Discussion: Optimising code for speed in GLBasic
« on: 2010-May-26 »
Hey Ian, I was thinking there is no way the Wiz and the GP2X can run your Shadow of the Beast demo at 60 fps and my Pentium 4 and Atom netbook can't do it. That's just not right and yet it really does run at about 10-15 fps on my Atom. So what's going on?
Are you by any chance loading the graphics you want to display as layered parallax using something like LOADANIM "beastbackground.png", x, 1, 480 where each line of animation is only 1 pixel wide and then displaying each line of your images by calling DRAWANIM for each line? If you are, that's a problem (for PC compiled code). DRAWANIM seems to be a relatively expensive command to call.
For an example if you wanted to cover an 800 x 600 screen with sprites I've found it would be much much faster to cover the screen completely 32 times over each frame by drawing 64 alpha-blended 800 x 300 sprites that it would be to completely cover the screen just once by using DRAWANIM to draw 800 lines as sprites that were 300 pixels in length! That's an incredible difference and shows how expensive it is to call the DRAWANIM function
If you need me to attach a zip file with some example code I'll do that. I just wanted to check the problem was what I thought it might be before I do that.
Are you by any chance loading the graphics you want to display as layered parallax using something like LOADANIM "beastbackground.png", x, 1, 480 where each line of animation is only 1 pixel wide and then displaying each line of your images by calling DRAWANIM for each line? If you are, that's a problem (for PC compiled code). DRAWANIM seems to be a relatively expensive command to call.
For an example if you wanted to cover an 800 x 600 screen with sprites I've found it would be much much faster to cover the screen completely 32 times over each frame by drawing 64 alpha-blended 800 x 300 sprites that it would be to completely cover the screen just once by using DRAWANIM to draw 800 lines as sprites that were 300 pixels in length! That's an incredible difference and shows how expensive it is to call the DRAWANIM function
If you need me to attach a zip file with some example code I'll do that. I just wanted to check the problem was what I thought it might be before I do that.