Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

139 Neutral

About TimA

  • Rank
  1. Okay....I really dislike the whole Eclipse with ADT set-up.  Drag and drop stuff onto a graphical representation of a phone/tablet, figure out where the code goes....not for me.  I'd rather just write everything by hand.  Is there any way to write Android apps without having that rediculous set-up?   Android apps are written in Java...great I thought, I already know Java.  But the Eclipse/ADT set-up looks rediculous to me.  I'd rather just know where the program entry point is, import/create the necessary files, hand-code the UI using the API and compile to an apk.   I'll admit I haven't messed around with it a whole lot...because I want to write code....not drag things onto the screen and set their properties.    I like Eclipse for regular PC applications.  You create the main class, give it a main() and you're good to go.  You want a GUI....import swing, set up the window with Frames and the like and you're good to go.  Took me an hour to understand that and a week to master (I'll fully admit I'm no Swing expert...but I can get a UI looking and behaving the way I want).  Android development....not as easy...at least not to me.    I feel like I have to not only learn the Android API, but also how to use Eclipse/ADT's goofy interface.  It also doesn't really outline a clear code-path.  I assume most apps are event-driven so there wouldn't be a clear code-path - but still, I'd rather know how all that fits together and have the code arranged in a way that makes sense to me for a particular project.    All I want to do is write a calendar app thats tailored to keeping track of my homework.  I have the entire design of this app already worked out in my head.  On a computer It'd take me at most 2 days to program it, and another day or 2 to debug and flesh out any major bugs.  A great starting app for android I thought - Simplistic, useful, and a perfect use of my free time between semesters.  I don't even know where to begin.  Normally I'd start writing the classes for everything, then design the UI, and then attach the UI to the underlying objects.  I can't even figure out how to get things to orient themselves the way I want.  I'd rather just write code that says create a textbox, position it this way (ie. LayoutManager), set this property to this, etc.    Is there anyway to create an android app strictly from writing code? No drag and drop, no running through 100's of files to find the one that holds the code for the one thing I want to write.  Just pure code.    Android is built on Linux, is all about open-source, a hacker/tinkerer's dream - not to mention all the cool sh*t inside the devices...like the accelerometer, HD camera, NFC, bluetooth, Wi-Fi....I guess I was expecting power tools, not fisher-price.    Can anyone link me to some tutorials that show how to write Android apps independent of an IDE.  I'd much rather write the XML files by hand and compile by command-line than figure out how to use a UI that looks like it was designed for a spastic toddler.  I'm starting to realize just why the Google Play store is plagued with moustache-trimming games and fake broken screen apps.  It's really frustrating.   Thanks in advance to anyone that can point me in the right direction.   PS - I prefer textual information over videos, but I'll take whatever I can get.
  2. Thanks for all the info, you've all gave me different aspects to consider when I decide to switch my map format over to binary.  Think I'm gonna save that task for after mid-terms though.
  3. A level editor is just a program that creates files.  How it does this is totally up to you.  You pick what data is necessary to save from the map (images to load, positions of objects, etc.).  You either have your level editor save this as plain text, or you save it as binary (raw bytes).   Your game will have a function for loading the map from a file.  How this function works will depend completely on how you wrote your save function (since it's effectively reversing it).    If you're asking how to create the GUI for the level editor, then it depends.  You can use SDL, SFML, Allegro, or any other graphics library if you're up for creating a bunch of form elements (picture boxes, menus, textboxes, etc.)  I think SDL has some 3rd party add-ons that help with that, not 100% on that though, haven't used it in a while.  Last I knew, SDL was capable of loading PNG's through SDL_image.  (windows binaries should be pre-built with it, in linux I assume it would have it as long as it compiled succesfully and found an appropriate version of libpng).    Another option would be to use something like FLTK (pronounced full-tick).  This is a library for creating GUI's and would probably make creating your level editor a lot quicker. http://www.fltk.org/shots.php   As for tutorials...googling SDL tutorials dropped these as the first two links:   www.sdltutorials.com/ lazyfoo.net/SDL_tutorials/index.php     but it's always good to read the API: http://www.libsdl.org/cgi/docwiki.fcg   So in short, what you want to learn: SDL, SFML, Allegro (your game, maybe your level editor, research these libraries, pick the best one for what you're making) C++ filestreams (loading and saving files) GUI-creation (graphic user interface for your level editor) How to use libraries (SDL is a library, FLTK is a library...libraries are your friend, learn to use them) How to read and understand API manuals (A library could be the most amazing thing on earth, if it doesnt have good documentation its useless)   Or you could just use someone elses level editor and just have a function in your game that knows how to read their map files.    
  4. Yeah the bool endianness was something I found online - ENDIAN getEndian() is what I was planning on calling it, returning an enumerated type defined right above it. Am I developing on multiple machines? No - I would like to develop with more than just my machines architecture in mind though. The library I'm more or less extending does all the low-level stuff inside. Not a whole lot of binary manipulation going on at my end. Except I am designing a binary file format to store map data and if someone creates a map on a big-endian system, and someone else loads it on a little-endian system it's either going to crash, or load something crazy. Awesome point about the constant sized data types - I will probably go that route. I have very little experience in cross-platform support, so if you wanna throw some links at me with some essential "you should know this so you don't f*ck everything up" type of info in it, I'd be appreciative, but other than loading binary file formats and data types being different sizes on different platforms I don't really see what platform specific code I'd need. I'll do more research later, right now I need to get to bed though...2 back to back math tests in 6 hours...yay *sarcasm* Edit: Cornstalks - just saw your post - awesomely informative and cleared up a lot of the gray area
  5. @ultramailman: Because so far I've read about systems with 16-bit, 24-bit, and 32-bit chars, some having a int the same size as char, and some having the same size long as int (though I don't really know the point of that) I agree that it should work with most systems if i were to evaluate something the size of char out of something the size of long long, it just seems bad practice to write something I know won't work in every situation.    @Bregma: No, I suppose this could happen at compile time, not sure how to go about that either though.  Seems like it'd be easier to do at run-time.
  6. Okay first off I found this: bool endianness() { int i = 1; char *ptr; ptr = (char*) &i; return (*ptr); } I like the way this is done, it's clever, quick and gets the job done.  Except it only really works if the size of an int is at-least twice the size of a char.  As I understand it the data types don't have a set size and that each 'larger' data type only has to be greater than or equal to the 'next smallest' data type.  Considering endianness is architecture specific, and the size of data types would differ on different architectures, this seems to be an unsafe assumption.    There's a lot of garbage information out there on endianness but from what I've gathered (and please correct me if I'm wrong):   char isn't guranteed to be one byte, it seems it's usually the size of whatever the processor processes things in, which is sometimes 16-bit (2 byte) increments   integer can be 1 byte on some architectures, which would break this code   I also have one question, is endianness byte ordering always based on 8-bit bytes or would it be ordered in sections of 16-bits on architectures with 16-bit chars?   I'm trying to accomplish something like this (pseudo-code): enum ENDIANNESS {UNKNOWN, LITTLE_ENDIAN, BIG_ENDIAN}; ENDIANNESS getEndian() { ENDIANESS e = UNKNOWN; get a 2 byte numeric data type; set bytes value equal to 1; get first byte if ( first byte == 0) { e = BIG_ENDIAN } else if ( first byte == 1) { e = LITTLE_ENDIAN } return e; }   Just not sure the best way to handle this, especially since I'm unclear on whether the byte order is based on 8-bits always (seems unlikely) or whatever the size of a char is on the system executing the code (seems more likely).    Any help is greatly appreciated :)
  7. You guys are awesome, thanks for all the info and quick response times.  The problem is now completely fixed and I learned a bit more about vectors.  I'll definitely be coming back next time I hit another snag I can't figure out.
  8. haha oooooh I see what I was doing now - thank you so much - is there anyway to initialize a vector in a class to a specific size in the constructor?  That's what I was trying to do, not create a local version of it.  Figured if I knew the starting size it'd be more efficient to create the vector to that size rather than using vector.push_back() to append a new element.  Do vectors allocate contiguous memory if initialized to size? I assume vectors can't do that when using push_back()? or maybe they re-create themselves after every added element so that it can fit into contiguous memory?
  9. I need the vector in the class populated with the sub-bitmaps - the constructor is meant to load a series of images into that vector to be stored.  Then characterAnimation::getNextFrame(void) will return the ALLEGRO_BITMAP* from the images vector when called from main.... ie.   main.cpp #include "allegro5/allegro.h" #include "character.h" bool isRunning = true; int main(void) { //allegro intialization stuff omitted ALLEGRO_BITMAP *spriteSheet = al_load_bitmap("characterSpriteSheet"); while(isRunning) { eventHandler(); al_draw_bitmap(walkingDown.getNextFrame(), 0, 0, 32, 32); //draws the current animation sequence al_flip_display(); //blits to screen } }  and the only difference in character.cpp is that the getNextFrame(void) function will look like this: ALLEGRO_BITMAP *characterAnimation::getNextFrame(void) { int tempStep = currentStep; if(currentStep == numberOfSteps) { currentStep = 0; } else { currentStep++; } return images[tempStep]; }   If i got rid of the member vector the class would be useless...unless I'm misunderstanding something.
  10. Alright it's been a while since I've programmed in C++ so this could be a simple fix but I'm just not seeing it.    I'm using Allegro 5, I have a main.cpp, a character.h, and a character.cpp   I have some test code in my main.cpp that works as it should: ALLEGRO_BITMAP *characterSpriteSheet = al_load_bitmap("CharacterSpriteSheet.png"); characterAnimation walkingDown(6, 32, 32, 0, characterSpriteSheet); std::vector <ALLEGRO_BITMAP*> testvector(1); testvector[0] = al_create_sub_bitmap(characterSpriteSheet, 0, 0, 32, 32); and then in the main game loop: al_draw_bitmap(al_create_sub_bitmap(testvector[0], 0, 0, 32, 32), 0, 0, 0); al_flip_display(); //Blit to screen   al_create_sub_bitmap creates an ALLEGRO_BITMAP* object that shares the same memory but with different size / clipping.     my character.h looks like this: #ifndef CHARACTER_H #define CHARACTER_H #include "allegro5/allegro.h" #include <vector> #include <string> class characterAnimation { public: characterAnimation(short int numOfSteps, short int height, short int width, short int row, ALLEGRO_BITMAP *spriteSheet); ALLEGRO_BITMAP *getNextFrame(void); private: short int numberOfSteps; short int currentStep; short int imageHeight; short int imageWidth; short int row; std::vector <ALLEGRO_BITMAP*> images; }; #endif   my character.cpp looks like this: #include "character.h" characterAnimation::characterAnimation(short int numOfSteps, short int height, short int width, short int animationRow, ALLEGRO_BITMAP *spriteSheet) { numberOfSteps = (numOfSteps - 1); currentStep = 0; imageHeight = height; imageWidth = width; row = animationRow; std::vector <ALLEGRO_BITMAP*> images(numberOfSteps); for(int x = 0; x <= numberOfSteps; x++) { images[x] = al_create_sub_bitmap(spriteSheet, (imageWidth * x), (imageHeight * row), imageWidth, imageHeight); } }  the characterAnimation::getNextFrame(void) function is currently setup just to return the first element (0) of the vector to make things easier right now (since it's not working)   The problem seems to be in characterAnimations constructor - I'm thinking that the al_create_sub_bitmap() created pointers goes out of scope and gets destroyed possibly at the end of the constructor? resulting in a bunch of pointers that don't go anywhere sensible.  Which would explain why my program crashes when I try to call al_draw_bitmap(images[x]).  My question is, is that what's happening?   Currently my program crashes only when I try to draw an element from characterAnimation::images to the screen, For some reason these pointers aren't getting set, or are being destroyed, I have no idea why though, so any help would be awesome.
  • 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!