Jump to content
  • Advertisement

guyaton

Member
  • Content Count

    259
  • Joined

  • Last visited

Community Reputation

130 Neutral

About guyaton

  • Rank
    Banned
  1. guyaton

    A few J2ME related questions

    It may be switching states too soon, I am not sure how you are displaying the splash screen, but I can think of 2 ways to fix it. One Try: try{ Thread.sleep( [milliseconds here] ); } catch( Exception e ) { } ***NOTE that this has to be done after the image is painted on the screen meaning that it can not happen in ur paint function or it must be after your flushGraphics (MIDP 2.0 with GameCanvas only). The other alternative, is to have the splash screen state have a counter and when that counter counts down to Zero, then switch to the Loading screen once that has happened. Hope that helps, ~guyaton
  2. guyaton

    A few J2ME related questions

    If you know what class should have the display at any given time, wouldn't it make sense to just change the display at that point time instead of keeping track of what comes next. For example, lets say your GameCanvas class will need to set the display after your loading class has completed. Could you do something like this? (following my source code that I had previously written) public class LoadingScreen implements Runnable { public LoadingScreen() { ; } public void run() { //load load //. //.for( m_iLoadingProgress=0; m_iLoadingProgress<m_LoadData.length; m_iLoadingProgress++ ) .... //. //blah blah ... end of loop //now we are exiting (loading complete) MyMIDlet.g_MyMIDlet.myGameCanvas = new GameCanvas(); new Thread( MyMIDlet.g_MyMIDlet.myGameCanvas ).start(); //Do this here to ensure that it is created AND loading is comlete Display.getDisplay( MyMIDlet.g_MyMIDlet ).setCurrent( MyMIDlet.g_MyMIDlet.myGameCanvas ); } This is assuming that MyMIDlet.g_MyMIDlet.myGameCanvas is a variable that is pointing to your game canvas class and is initially null. Some people say that pointers are evil, in this case I think they are extremely useful. Does that help or make any sense? ~guyaton
  3. guyaton

    mobile games

    While this question should be posted in this forum, I will answer your questions. There are a few different languages you can program in, but it is limited to a few factors: the carriers and the phones. For example, in America the Carrier Sprint is mostly J2ME, while Verizon is BREW. Some of the Smart phones also support .NET languages too. As far as starting points, I reccoment the FAQ which has a great start. Java is simular to C++ and C# and is relatively easy (if not quirky) to pick up. Hope that's a good starting point for you. ~guyaton some links for you if u want to learn java J2SE for the compiler and Tools J2SE download J2ME MIDP2.0 Wireless toolkit J2ME MIDP 2.0 Wireless toolkit download EDIT: beaten on the wrong forum.
  4. guyaton

    A few J2ME related questions

    Sorry I didn't get a chance to reply over the weekend. I am writting a little demo in J2ME which I will post once I am completed. I personaly like viewing other peoples code instead of someone just telling me how to do it. It should be sometime today. I will edit this post once completed. ~guyaton EDIT: Done! I would like to point out, that this code is not a representation from my work at Gameloft, SA, nor is it copied, borrowed, stolen or in anyway taken from any source code from my company of employment. This code was written solely by me at home and is free for use by anyone who wants to borrow, edit or make changes to the sourcecode as need be. It it a quick demo and could probably use a few tweaks. This has not yet been tested on a phone, as I do not have a J2ME phone of my own to test it on, however it works fine on the MIDP2.0 emulator provided by Sun. Ok....enough of that jibber jabber...here it is: MyMIDlet.java import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class MyMIDlet extends MIDlet { //This is in case it is needed anywhere else, with J2ME, less is more. public static MyMIDlet g_MyMIDlet = null; //This is the pointer to our canvas class which controls everything public MyCanvas m_MyCanvas = null; public MyMIDlet() { g_MyMIDlet = this; } //Remeber this is called when the phone is interrupted too. public void startApp() throws MIDletStateChangeException { if( m_MyCanvas == null ) { m_MyCanvas = new MyCanvas(); new Thread( m_MyCanvas ).start(); } Display.getDisplay( this ).setCurrent( m_MyCanvas ); } public void pauseApp() { notifyPaused(); } public void destroyApp( boolean b ) throws MIDletStateChangeException { notifyDestroyed(); } } MyCanvas.java import javax.microedition.lcdui.*; public class MyCanvas extends Canvas implements Runnable { public static final int STATE_STARTUP = 0; public static final int STATE_RUNNING = 1; public static final int STATE_LOADING = 2; public static final int STATE_CLOSE = 3; public int m_iState = STATE_STARTUP; //Some basic loading stuff public String m_strLoadingText = "Loading."; public int m_iNumLoaded = 0; public int m_iStateCtr = 0; //This is where we are going to load the images. Its not the best example, //but for a quick example here, it works. public static Image m_Images[] = null; //Basic images that there are to load. If you use an OBFUSCATOR, most of the //static ints will disappear in the final .class files making smaller jars. public static final int LOAD_IMAGE1 = 0; public static final int LOAD_IMAGE2 = 1; //This tells us when the loading has completed in the seperate thread. public static boolean m_bLoadingComplete = false; //This is a pointer to the loading class. public LoadingMechinism m_LoadingMeshPtr = null; //Not complex enough to need anything here. public MyCanvas() { ; } //basic run loop. public void run() { //Any intialization code would go here SwitchState( STATE_LOADING ); //main loop while( m_iState != STATE_CLOSE ) { System.out.println( "run" ); repaint(); serviceRepaints(); try { Thread.sleep( 50 ); } catch( Exception e) {} System.gc(); } } //for simplicity sake (and backwards compatibility) I opted to use MIDP 1 //canvas so theoretically, this should work on MIDP 1 as well. public void paint( Graphics g ) { //For now we just call this, can be implimented differently StateMachine( g ); } //any specific state startup stuff here public void SwitchState( int iNewState ) { m_iStateCtr = 0; m_iState = iNewState; switch( iNewState ) { case STATE_STARTUP: break; case STATE_RUNNING: break; case STATE_LOADING: m_bLoadingComplete = false; System.out.println( "SwitchState: STATE_LOADING" ); int LoadArray[] = new int[2]; LoadArray[0] = LOAD_IMAGE1; LoadArray[1] = LOAD_IMAGE1; //This is probably not what you want to do. You may want to include //a local pointer to the LoadingMechinism class and do somethign like this m_LoadingMeshPtr = new LoadingMechinism( LoadArray ); new Thread( m_LoadingMeshPtr ).start(); //this way you can //new Thread( new LoadingMechinism( LoadArray ) ).start(); System.gc(); break; } } //This is called once per frame public void StateMachine( Graphics g ) { System.out.println( "StateMachine: " + m_iState ); switch( m_iState ) { case STATE_STARTUP: g.setClip( 0, 0, 200, 200 ); g.setColor( 0 ); g.fillRect( 0, 0, 200, 200 ); break; case STATE_RUNNING: System.out.println( "Loading Complete" ); g.setClip( 0, 0, 200, 200 ); g.setColor( 0 ); g.fillRect( 0, 0, 200, 200 ); g.setColor( 0xffffff ); g.drawString( "Loding Complete!!", 100, 100, Graphics.HCENTER|Graphics.TOP ); break; case STATE_LOADING: //once the loading is complete, change the state. if( m_bLoadingComplete ) { SwitchState( STATE_RUNNING ); return; } //all the other times, lets just show the loading bar, while //we are loading g.setClip( 0, 0, 200, 200 ); g.setColor( 0 ); g.fillRect( 0, 0, 200, 200 ); if( m_iNumLoaded > 7 ) { m_iNumLoaded = 0; m_strLoadingText = "Loading."; } m_strLoadingText += " ."; m_iNumLoaded++; g.setColor( 0xffffff ); g.drawString( m_strLoadingText, 100, 100, Graphics.HCENTER|Graphics.TOP ); System.out.println( "StateMachine: STATE_LOADING" ); //If you want, you can use the counter in LoadingMechinism to get the current index //and use that to draw the loading bar g.setColor( 0xff0000 ); g.fillRect( 0, 140, m_LoadingMeshPtr.GetLoadingProgress()*100, 7 ); break; } } } LoadingMechinism.java import javax.microedition.lcdui.*; public class LoadingMechinism implements Runnable { private int m_LoadData[] = null; private int m_iLoadingProgress = 0; //For this example, we simply pass in whatever we want to load as param 1 public LoadingMechinism( int Arr[] ) { m_LoadData = new int[Arr.length]; System.arraycopy( Arr, 0, m_LoadData, 0, Arr.length ); } //This allows other classes to see how much we've loaded public int GetLoadingProgress() { return this.m_iLoadingProgress; } //A simple for loop, will allow this thread to die when it finishes. public void run() { //delete all old images. MyCanvas.m_Images = null; //garbage collect to ensure we have enough space to load. System.gc(); //create the images that we will be loading. This could be tweaked, or //changed for more diserable loading. MyCanvas.m_Images = new Image[m_LoadData.length]; //loop through everything that needs to be loaded. for( m_iLoadingProgress=0; m_iLoadingProgress<m_LoadData.length; m_iLoadingProgress++ ) { System.out.println( "Running loadign mech" ); switch( m_iLoadingProgress ) { //image 1 case MyCanvas.LOAD_IMAGE1: try { MyCanvas.m_Images[m_iLoadingProgress] = Image.createImage( "/images.png" ); } catch( Exception e ) { System.out.println( "Error loading image /images.png " + e.toString() ); } break; //Image 2 case MyCanvas.LOAD_IMAGE2: try { MyCanvas.m_Images[m_iLoadingProgress] = Image.createImage( "/image1.png" ); } catch( Exception e ) { System.out.println( "Error loading image /image1.png " + e.toString() ); } break; } //Always have a sleep in the run methods so other threads can work, such //as the painting (canvas) thread. try { Thread.sleep( 50 ); } catch( Exception e ) {} } MyCanvas.m_bLoadingComplete = true; } } [Edited by - guyaton on February 20, 2006 2:35:05 PM]
  5. guess there must be a bug with Visual Studio .NET 2003 [grin] surprise surprise! ~guyaton EDIT: A friend of mine came up with this: unsigned int max(unsigned int a, unsigned int b) { unsigned int adivb = (a+1)/(b+1); unsigned int bdiva = (b+1)/(a+1); unsigned int bMax = ((adivb * 2 + 1) / (adivb + 2)); unsigned int aMax = ((bdiva * 2 + 1) / (bdiva + 2)); return bMax * b + aMax * a; }
  6. This is outside the box and may not work in all situations (or may not even work for all compilers) but since it wasn't specified whether C or C++ was allowed, does this work for all cases? (Note in advance: I never said it was fast, nor do I know if try...catch() is allowed, but worth a shot) unsigned int max( unsigned int Mx1, unsigned int Mx2 ) { try { unsigned int result = Mx1 / Mx2; try { //with vs.net 2003, the exception WILL be caught result = 1 / result; return Mx1; } catch( ... ) { ; } return Mx2; } catch( ... ) { ; } return Mx1; } ~guyaton
  7. guyaton

    A few J2ME related questions

    Looking it over, I found a few possible issues and a few possible fixes. this line in your constructor isn't really needed: loadingScreen=null; Instead you could just set the loadingScreen to null when declaire it. Ie. LoadingScreen loadingScreen = null; (OK, ok not a major issue, but...). The next line after that in your constructor you do this: loadingScreen = new LoadingScreen(this); I think this is a HUGE problem. Why? Well, the constructor is called, but then the function startApp() is called which has these lines: this.display = Display.getDisplay(this); this.display.setCurrent( this.menuScreen ); display.setCurrent(loadingScreen); Only one Item can be have the display at any current time, so setting MenuScreen and loadingScreen could have undesireable effects. I feel that the flow of your game is kind of lacking, so this is how I would recommend fixing it (Feel free anyone to add or fix my suggestion): MenuMidlet constructor: just create all the basic stuff, don't create any of the actual classes yet. MenuMidlet startApp() Here is where you are going to create the classes that you need. Also remember that on *MOST* phones, startApp() is called after the phone returns from an interrupt, so make sure you check that your GameCanvas class is null before creating it. Why create an isntance of the GameCanvas class here? Well from what I can tell, the GameCanvas class is what controlls the entire project really, so here in the GameCanvas class is where you want to create the LoadingScreen class as you need it. This class would probably be the ideal class to store your State Manager (however you choose to impliment it). When the state is set to loading time, create the LoadingScreen class, set the display to the LoadingScreen class, and run the thread until it finishes, making sure you set the display back when finished. Another idea, is to keep the GameCanvas class as the rendering class, and have the LoadingScreen solely the loading class, but that's entirely up to you. If you follow this approach, CommandListener does not need to be implimented by the MIDlet class, saving you some space in your .jar for other things (artwork, music etc.) try that out first and let me know how it goes. ~guyaton
  8. guyaton

    A few J2ME related questions

    Reviewing the LoadingScreen class, I am curious, why are you doing this in your constructor: myMidlet = new MenuMidlet(); In my experiences, you never need to create MIDlets as J2ME is kind enough to do this for us. When the Java app is first started, it creates an instance of the MIDlet that we will use throughout the entire project's/application's runtime. In some cases, the MIDlet should control the flow of the game, and be what creates the Menu and the Loading class as needed, otherwise, you could have a cGame class (for example) that controls what is displayed and what happens throughout the course of the game. The advantage of the second way, is that only one (1) version of hideNotify()/showNotify() pair will need to be written, as the one in the cGame class will take care of all necessary cleanup or reseting of states. As far as the Exception that is being thrown, I have not seen it yet in J2ME, but in J2SE google told me that it can mean that your either trying to access a restricted class, file or object that you are not allowed to. Other then that, I don't see anything that jumps out at me as an error. As always, let me know what else you need help on. ~guyaton
  9. guyaton

    A few J2ME related questions

    From what I have found writting J2ME is that when writting the loading portion of the application, you don't want the loading class to Render. Why is this you ask? The reason is simple, on a lot of "average" phones, they are not very good at doing certain things, one of the major ones, is loading resources. The best way to do this, is have the loading in a seperate class, so that the rendering cna be done in a different thread allowing both of them to update at the same time. If you don't, you may see the odd results, such as the phone getting a phone call, and as it resumes it may not repaint because it is still trying to load a resource. Another advantage, is you can do other things on screen, such as text that changes as while the Loading Bar is being incremented or other cool effects. Now that you have the basics, this is some more exciting stuff that you can do. As far as an IDE, I am personally not a fan of NetBeans (maybe it has something to do with the fact that I'm not a fan of Java in general and how if I leave NetBeans on for a long time it can steal 200 to 300 MB of RAM easily). I use either JCreator (there is a free version) or Textpad and use build scripts to do the actual compilations. Other then that, what you have is a good starting pointfor your loading engine. If you have any more questions feel free to ask me! ~guyaton
  10. guyaton

    A few J2ME related questions

    Few changes that I see that are very obvious to me: Main MIDlet: 1) public Display getDisplay() { return display; } *** not needed. If you ever need the display, just do: Display.getDisplay( MainMIDlet /*or whatever ur MIDlet Class is*/).setCurrent( /*some Displayable*/ ); 2) If you want to use Threads with the LoadingScreen class, it needs to impliment Runnable. public class LoadingScreen extends Canvas impliments Runnable { public void run() { //this will terminate the thread as soon as the counter reaches whatevre value it should reach. while( counter < MAX_CTR_VAL ) { repaint(); serviceRepaints(); try { Thread.sleep( 50 ); } catch( Exception e ){} } } 3) paintThread= new Thread(this); paintThread.start(); repaint(); *** Remove these 3 lines and replace the only the first 2 should belong in the constructor. (It will work now that you've implimented runnable). 4) One small optomization to do, is in the LoadingScreen class: private int k = 160/2; ***Instead of dividing by 2, its faster (especially if you are doing it alot) to bitshift one. So in other words: private int k = 160>>1; 5) One thing that I have found very useful, is in the "main" MIDlet class always have a static variable that keeps an instance of the MIDlet, for example: public MyMIDlet extends MIDlet { MyMIDlet m_PublicMyMIDlet = null; MyMIDlet() { PublicMyMIDlet = this; } 6) In the constructor of the LoadingScreen class, add this in the constructor: Display.getDisplay( /*MIDlet class here, from fix 5: MyMIDlet.m_PublicMyMIDlet*/ ).setCurrent( this ); I haven't had a chance to look through the GameScreen class yet. I will have to check that out later. ~guyaton
  11. guyaton

    A few J2ME related questions

    This question actually depends a lot on the hardware you are running it on. Some phones are slower then others or may have less heap and therefore need to be compensated accordingly. Another thing to be aware of, GOOD framerate on phones is horrible frame rate on computers, so don't be shocked if you see frame rate that is low. On some decent handsets that I've worked on 12-15 fps was considered good. To start, of course you need some image (I would recommend .png as they support transparency), and this image can be composed many different ways. The easiest way is for the image to compose frames that make up the animations. For example: (Assume this is a png file here) | Walk frame 1 | Walk frame 2 | ...etc | Run frame 1 | Run frame 2 | ...etc Each series of animations may take a different amount of time for them to complete, so you may want to create constants for those. Then u can just interpolate over time. Making sure to set you clips to show only the current frame in the animation. You will also need tile layers. It depends on how complex you want the scene to be, but I think 4 frames will probably provide you with a nice looking scene. The tile layers COULD be as follows: (in order of drawing to the screen) * Background (probably just a static image that you can draw such as sky etc) * Forground layer (your main level) * The main character and enemies * a sprite or "action" layer (such as bullets, fire from various traps, explosions, etc. ) The forground layer is best when subdivided into smaller peices so that it can be reused throughout the game. For example: a brick in mario world, you just have 1 image of a brick, and u draw it over and over instead of 1 BIG tile that contains all the brinks). The most efficient way to do this, is to use a back buffer (which is really just an Image that you create of varying width and height. In most cases (depends on the phone) you want to create this image larger then the screen size. You draw everything to this image first, getting the Graphics like this: Image someImage = new Image.createImage( 400, 800 ); Graphics g = someImage.getGraphics(); Then you draw the 2 base layers on to that and from there you use the backbuffer to draw the background, then draw the top layers so that you minimize the actual graphics calls you make. This is a link I found on Google, which might help you out a little bit. hope this helps, ~guyaton
  12. guyaton

    Pak Files

    You don't need to extract them anywhere. There are function calls that will load from a void*. For example here are 2 functions: D3DXLoadMeshHierarchyFromXInMemory D3DXCreateTextureFromFileInMemory which should be in the DirectX Help files that come with DirectX. ~guyaton
  13. guyaton

    A few J2ME related questions

    You must have some kind of state machine in the application right? Just create a new state that will represent the loading. I am not sure how your state machine runs, but the loading state itself will also need substates. In each substate, you want to do a small portion of the loading. For example, one image or some data file. Once each resource is loaded, you would exit the function, allowing other aspects of the app (mainly the paint() function) to be called, which will draw the updated bar based on how far along in the state you are. As far as needing another class, I am guessing not, but it totally depends on how your application is set up. You will know if certain images are loaded, by whether or not your load function threw in error, in which case that would need to be handled accordingly. Hope this answers your questions, ~guyaton
  14. guyaton

    A few J2ME related questions

    Creating a bar can be as complex or as a simple as you want. One quick way to do it, would be to use fillRect() and draw on the screen based on a counter that you use. This counter could be updated many ways, from a switch statement that loops through after every call to paint() or in a seperate thread that has access to a static or public member variable in one of your classes. pseudocode could be(not tested) private int m_iLoadingProgess = 0; public void paint( Graphics g ) { LoadSomething(); g.setColor( 0xff2345 ); //dunno what color that is...but good for demonstration g.fillRect( kScreenHeight>>1, 0, kScreenHeight>>1 + 10, iLoadingProgess * 5 ); //kScreenHeight is a constant for the screen height } public void LoadSomething() { switch( m_iLoadingProgess ) { case 0: //load resource A case 1: //Load resource B case 2: //load resource C //exit the loading section default: Loading and saving issues are pretty easy. Use J2ME's RecordStore classes. use addRecord() to create a new record in the record store, and then setRecord() to update a currently get a new record or getRecord() to get the data from a record store. One peice of advice that I do is use constants to define where in the record store everything is. for example recordstore 1 (yes...j2me starts with 1 not 0 ) could be the characters Life. 2 could be level...et cetera. Some people prefer to store everything in RecordStore slot 1 as a byte array that way its more like reading a file. that's fine too. hope that gets u off in the right direction. ~guyaton
  15. Direct3D has this function to render either wireframe or solid this->mpD3DDevice->SetRenderState( D3DRS_FILLMODE, D3DFILL_WIREFRAME ); or this->mpD3DDevice->SetRenderState( D3DRS_FILLMODE, D3DFILL_SOLID ); is there an OpenGL equivalent? thanks in advance, ~guyaton
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!